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The  Research  and  Technology 
Organisation  (RTO)  of  NATO 


RTO  is  the  single  focus  in  NATO  for  Defence  Research  and  Technology  activities.  Its  mission  is  to  conduct  and  promote 
co-operative  research  and  information  exchange.  The  objective  is  to  support  the  development  and  effective  use  of 
national  defence  research  and  technology  and  to  meet  the  military  needs  of  the  Alliance,  to  maintain  a  technological 
lead,  and  to  provide  advice  to  NATO  and  national  decision  makers.  The  RTO  performs  its  mission  with  the  support  of  an 
extensive  network  of  national  experts.  It  also  ensures  effective  co-ordination  with  other  NATO  bodies  involved  in  R&T 
activities. 


RTO  reports  both  to  the  Military  Committee  of  NATO  and  to  the  Conference  of  National  Armament  Directors. 
It  comprises  a  Research  and  Technology  Board  (RTB)  as  the  highest  level  of  national  representation  and  the  Research 
and  Technology  Agency  (RTA),  a  dedicated  staff  with  its  headquarters  in  Neuilly,  near  Paris,  France.  In  order  to 
facilitate  contacts  with  the  military  users  and  other  NATO  activities,  a  small  part  of  the  RTA  staff  is  located  in  NATO 
Headquarters  in  Brussels.  The  Brussels  staff  also  co-ordinates  RTO’s  co-operation  with  nations  in  Middle  and  Eastern 
Europe,  to  which  RTO  attaches  particular  importance  especially  as  working  together  in  the  field  of  research  is  one  of  the 
more  promising  areas  of  co-operation. 


The  total  spectrum  of  R&T  activities  is  covered  by  the  following  7  bodies: 


•  AVT 

•  HFM 

•  1ST 

•  NMSG 

•  SAS 

•  SCI 

•  SET 


Applied  Vehicle  Technology  Panel 
Human  Factors  and  Medicine  Panel 
Information  Systems  Technology  Panel 
NATO  Modelling  and  Simulation  Group 
System  Analysis  and  Studies  Panel 
Systems  Concepts  and  Integration  Panel 
Sensors  and  Electronics  Technology  Panel 


These  bodies  are  made  up  of  national  representatives  as  well  as  generally  recognised  ‘world  class’  scientists.  They  also 
provide  a  communication  link  to  military  users  and  other  NATO  bodies.  RTO’s  scientific  and  technological  work  is 
carried  out  by  Technical  Teams,  created  for  specific  activities  and  with  a  specific  duration.  Such  Technical  Teams  can 
organise  workshops,  symposia,  field  trials,  lecture  series  and  training  courses.  An  important  function  of  these  Technical 
Teams  is  to  ensure  the  continuity  of  the  expert  networks. 


RTO  builds  upon  earlier  co-operation  in  defence  research  and  technology  as  set-up  under  the  Advisory  Group  for 
Aerospace  Research  and  Development  (AGARD)  and  the  Defence  Research  Group  (DRG).  AGARD  and  the  DRG  share 
common  roots  in  that  they  were  both  established  at  the  initiative  of  Dr  Theodore  von  Karman,  a  leading  aerospace 
scientist,  who  early  on  recognised  the  importance  of  scientific  support  for  the  Allied  Armed  Forces.  RTO  is  capitalising 
on  these  common  roots  in  order  to  provide  the  Alliance  and  the  NATO  nations  with  a  strong  scientific  and  technological 
basis  that  will  guarantee  a  solid  base  for  the  future. 


The  content  of  this  publication  has  been  reproduced 
directly  from  material  supplied  by  RTO  or  the  authors. 


Published  February  2012 

Copyright  ©  RTO/NATO  2012 
All  Rights  Reserved 

ISBN  978-92-837-0154-5 


Single  copies  of  this  publication  or  of  a  part  of  it  may  be  made  for  individual  use  only.  The  approval  of  the  RTA 
Information  Management  Systems  Branch  is  required  for  more  than  one  copy  to  be  made  or  an  extract  included  in 
another  publication.  Requests  to  do  so  should  be  sent  to  the  address  on  the  back  cover. 
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Executive  Summary 

In  recognition  of  current  and  anticipated  operations,  NATO  established  the  need  for,  and  initiated 
development  of,  a  distributed  and  networked  education  and  training  capability  subsequently  titled  the  NATO 
Education  and  Training  Network  (NETN).  NETN  originated  to  integrate  and  enhance  existing  national 
capabilities  and  focus  on  the  education  and  training  of  NATO  Operational  and  Tactical  Headquarters’  staffs 
and  NATO  forces  preparing  to  execute  NATO  Response  Force  (NRF),  Combined  Joint  Task  Force  (CJTF), 
International  Security  and  Assistance  Force  (ISAF)  and  other  future  NATO  missions.  For  these  missions 
NATO  provides  and  trains  combined  headquarters,  and  Nations  assign  trained  tactical  forces.  Therefore, 
the  training  of  the  combined  headquarters  is  the  responsibility  of  NATO  while  Nations  are  responsible  for 
the  tactical  training  of  the  assigned  forces.  An  NETN  consisting  of  a  persistent  infrastructure,  distributed 
training  and  education  tools,  and  standard  operating  procedures  not  only  supports  the  training  of  NATO 
headquarters  but  also  enables  the  Nations  to  collaborate  with  each  other  to  train  their  tactical  forces  and 
headquarters.  NETN  promises  a  more  efficient  and  less  costly  capability  for  these  purposes,  and  broader 
and  deeper  interoperability.  Moreover,  it  also  introduces  an  opportunity  to  integrate  the  training  of  NATO 
headquarters  (i.e.,  both  technically  and  procedurally)  with  the  tactical  forces  when  needed  for  short  notice 
mobile  mission  rehearsal  training  and  other  integrated  exercise  requirements. 

Current  and  emerging  operational  requirements  increase  the  need  for  a  highly  available,  agile,  flexible 
and  cost-effective  NETN.  Existing  capabilities  such  as  the  NATO  Airborne  Early  Warning  and  Control 
(AEW&C)  and  enhanced  capabilities  such  as  Unmanned  Aerial  Vehicle,  Joint  Intelligence,  Surveillance  and 
Reconnaissance  capabilities,  Friendly  Force  Trackers,  C-IED,  and  Cyber  Defence  are  being  integrated  into 
ISAF  and  the  NRF  operations  and  preparations.  New  capabilities  such  as  the  Air  Command  and  Control 
Systems  (ACCS),  Airborne  Ground  Surveillance  (AGS)  and  Active  Fayer  Theatre  Ballistic  Missile  Defence 
(AFTBMD)  are  also  in  development.  Additionally,  NATO  is  increasingly  operating  alongside  non-NATO 
military  as  well  as  Non-Governmental  Organizations  (NGO),  placing  additional  demands  on  current  NATO 
tactics,  techniques,  and  procedures.  This  combination  of  enhanced  capabilities  and  evolving  operational 
requirements  are  imposing  new  training  requirements.  For  these  reasons  there  is  an  essential  need  for  a 
common  NATO  training  and  education  distributed  environment  to  boost  standardization  and  interoperability, 
and  at  the  same  time  to  reduce  duplication  of  effort  and  to  enhance  the  efficient  use  of  resources. 

To  meet  this  operational  demand,  Allied  Command  Transformation  (ACT)  requested  that  NATO  Modelling 
and  Simulation  Group  (NMSG)  start  a  technical  activity  in  2006.  NMSG  tasked  an  Exploratory  Team 
(ET-025)  to  analyze  the  requirement  and  start  a  technical  activity.  ET-025  formed  Modelling  and  Simulation 
Group  068  (MSG-068  NETN)  for  this  purpose  in  2007.  NATO  Joint  Warfare  Center  assigned  the  chair  for 
MSG-068.  Apart  from  NATO  JWC,  Headquarter  Supreme  Allied  Command  Transformation  (HQ-SACT), 
Joint  Forces  Training  Center  (JFTC),  NATO  Consultancy,  Command  and  Control  Agency  (NC3A)  and 
13  Nations  (Australia,  Bulgaria,  France,  Germany,  Hungary,  Netherlands,  Romania,  Slovenia,  Spain, 
Sweden,  Turkey,  UK,  USA)  supported  MSG-068.  The  MSG-068  NETN  Task  Group  (TG)  assessed  the 
distributed  simulation  and  learning  capabilities  that  could  contribute  to  the  development  of  an  NETN 
capability.  The  Task  Group  (TG)  recommends  and  demonstrates  a  way  forward  for  interoperability, 
technical  standards  and  architectures  to  link  the  NATO  and  national  training  and  education  centres  to 
provide  a  persistent  capability,  and  also  identifies  and  recommends  roles  and  responsibilities  of  the  NATO, 
Partner  and  Contact  Nation  organizations  within  the  scope  of  NETN. 


RTO-TR-MSG-068 


ES-1 


MSG-068  recommendations  need  to  be  implemented  by  NATO  and  the  Nations  to  achieve  the  NETN 
vision.  MSG-068  recommends  either  a  new  capability  package  or  an  amendment  to  an  existing  capability 
package  to  act  on  the  recommendations. 
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Synthese 

A  la  lumiere  d’enseignements  tires  des  operations  en  cours  et  anticipees,  l’OTAN  a  etabli  qu’une  capacite 
de  formation  et  d’entrainement  distribute  et  en  reseau  etait  necessaire  et  a  commence  a  la  developper, 
sous  le  nom  de  Reseau  OTAN  de  formation  et  d’entrainement  (NETN).  Le  NETN  a  ete  congu  pour  integrer 
et  ameliorer  les  capacites  nationales  existantes  et  se  concentrer  sur  l’education  et  l’entrainement  des 
personnels  des  etats-majors  operationnels  et  tactiques  de  l’OTAN  et  des  forces  de  l’OTAN  se  preparant  a 
assurer  une  mission  de  force  d’intervention  de  l’OTAN  (NRF),  de  groupement  de  forces  interarmees 
multinationales  (CJTF),  de  force  intemationale  de  securite  et  d’ assistance  (ISAF)  et  d’autres  futures  missions 
de  l’OTAN.  Pour  ces  missions,  l’OTAN  foumit  et  entraine  des  etats-majors  interallies  et  les  nations  affectent 
des  forces  tactiques  entrainees.  Par  consequent,  l’entrainement  des  etats-majors  interallies  est  la 
responsabilite  de  l’OTAN  tandis  que  les  nations  sont  responsables  de  l’entrainement  tactique  des  forces 
affectees.  Un  NETN,  compose  d’une  infrastructure  permanente,  d’outils  d’entrainement  et  d’education 
repartis  et  d’ instructions  permanentes  ne  soutient  pas  seulement  l’entrainement  des  etats-majors  de  l’OTAN, 
mais  permet  egalement  aux  nations  de  collaborer  entre  elles  pour  entrainer  leurs  forces  et  etats-majors 
tactiques.  Le  NETN  laisse  envisager  une  capacite  plus  efficace  et  moins  couteuse  dans  ce  but  et  une 
interoperabilite  plus  vaste  et  plus  approfondie.  Qui  plus  est,  il  donne  l’occasion  d’integrer  l’entrainement  des 
etats-majors  de  l’OTAN  (c’est-a-dire,  techniquement  et  sur  le  plan  procedural)  avec  les  forces  tactiques  si 
necessaire  pour  une  mission  projetee  a  court  preavis  et  pour  d’autres  besoins  d’exercices  integres. 

Les  besoins  operationnels  actuels  et  nouveaux  accroissent  la  necessite  d’un  NETN  tres  disponible,  agile, 
souple  et  economique.  Les  capacites  existantes  telles  que  le  systeme  aeroporte  de  controle  et  d’alerte  avancee 
OTAN  (AEW&C)  et  les  capacites  ameliorees  telles  qu’un  vehicule  aerien  sans  pilote,  le  renseignement 
interarmees,  les  capacites  de  surveillance  et  de  reconnaissance,  les  systemes  de  localisation  de  forces  amies, 
la  lutte  contre  les  IED  et  la  cyber  defense  sont  integres  dans  les  operations  et  preparations  de  1’ISAF  et  de  la 
NRF.  De  nouvelles  capacites  telles  que  le  systeme  de  commandement  et  de  controle  aeriens  (ACCS), 
la  surveillance  du  sol  aeroportee  (AGS)  et  la  defense  multicouche  active  contre  les  missiles  balistiques  de 
theatre  (ALTBMD)  sont  egalement  en  cours  de  developpement.  De  plus,  l’OTAN  opere  de  plus  en  plus  aux 
cotes  de  militaires  non  membres  de  l’OTAN  ainsi  que  d’ organisations  non  gouvemementales  (NGO),  ce  qui 
ajoute  des  exigences  vis-a-vis  des  tactiques,  techniques  et  procedures  actuelles  de  l’OTAN.  Cette  combinaison 
de  capacites  ameliorees  et  de  besoins  operationnels  changeants  impose  de  nouveaux  besoins  d’entrainement. 
Pour  ces  raisons,  un  environnement  commun  d’entrainement  et  d’education  reparti  est  necessaire  a  l’OTAN 
afin  de  stimuler  la  standardisation  et  1’ interoperabilite  et  en  meme  temps  reduire  la  repetition  inutile  d’efforts 
et  ameliorer  l’utilisation  efficace  des  ressources. 

Pour  repondre  a  cette  demande  operationnelle,  le  Commandement  allie  Transformation  (ACT)  a  demande 
que  le  Groupe  OTAN  sur  la  modelisation  et  la  simulation  (NMSG)  debute  une  activite  technique  en  2006. 
Le  NMSG  a  charge  une  equipe  exploratoire  (ET-025)  d’analyser  le  besoin  et  de  commencer  une  activite 
technique.  Dans  cet  objectif,  l’ET-025  a  forme,  en  2007,  le  Groupe  de  modelisation  et  simulation  068 
(MSG-068  NETN).  Le  Centre  de  guerre  interarmees  (JWC)  de  l’OTAN  a  nomme  le  president  du  MSG-068. 
Outre  le  JWC  de  l’OTAN,  l’etat-major  du  Commandement  supreme  allie  Transformation  (HQ-SACT), 
le  Centre  d’entrainement  des  forces  interarmees  (JFTC),  l’Agence  de  consultation,  de  commandement  et  de 
controle  de  l’OTAN  (NC3A)  et  13  nations  (Australie,  Bulgarie,  France,  Allemagne,  Hongrie,  Pays-Bas, 
Roumanie,  Slovenie,  Espagne,  Suede,  Turquie,  Royaume-Uni,  Etats-Unis)  ont  soutenu  le  MSG-068. 
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Le  groupe  de  travail  NETN  du  MSG-068  a  evalue  les  capacites  d’apprentissage  et  de  simulation  reparties  qui 
pouvaient  contribuer  au  developpement  d’une  capacite  NETN.  Le  groupe  de  travail  recommande  et  ouvre  la 
voie  vers  des  normes  techniques  et  d’interoperabilite  et  des  architectures  pour  relier  les  centres  d’entrainement 
et  d’education  nationaux  et  ceux  de  l’OTAN  afin  de  foumir  une  capacite  durable  ;  il  identifie  et  recommande 
les  roles  et  responsabilites  de  l’OTAN,  des  organisations  nationales  partenaires  et  de  contact  dans  le  champ 
d’ application  du  NETN. 

Les  recommandations  du  MSG-068  doivent  etre  mises  en  application  par  l’OTAN  et  les  nations  pour 
realiser  la  vision  du  NETN.  Le  MSG-068  recommande  soit  un  ensemble  de  nouvelles  capacites,  soit  la 
modification  d’un  ensemble  existant  pour  suivre  les  recommandations. 
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NATO  EDUCATION  AND  TRAINING  NETWORK 

1.0  INTRODUCTION 

In  the  light  of  future  operations  and  real-life  challenges,  NATO  is  recognising  the  need  for  development  of  a 
distributed  and  networked  education  and  training  capability  which  will  integrate  and  enhance  existing  national 
capabilities  and  will  focus  on  the  education  and  training  of  NATO  Operational  and  Tactical  Headquarters’ 
staffs  and  NATO  forces  preparing  to  execute  NATO  Response  Force  (NRF),  Combined  Joint  Task  Force  (CJTF) 
and  International  Security  and  Assistance  Force  (ISAF)  and  any  other  future  NATO  missions. 

To  meet  this  operational  demand,  NATO  Allied  Command  Transformation  (ACT)  established  a  vision  to: 

Deliver  to  Alliance  and  Partners  a  persistent,  distributed  education  and  training  capability  able 
to  support  training  spanning  from  strategic  down  to  tactical  level  across  the  full  spectrum  of 
operations,  leveraging  national  expertise  and  capabilities. 

ACT  initiated  the  NATO  Snow  Leopard  program  to  accomplish  this  vision.  Snow  Leopard  is  synonymous 
with  NETN.  NATO  Snow  Leopard  is  composed  of  the  following  components: 

•  Education; 

•  Shared  scenarios;  and 

•  Modelling  &  Simulation  (M&S)  toolsets. 

All  of  them  distributed  over  NATO  Wide  Area  Network  (WAN). 

The  WAN  includes  but  is  not  limited  to  NGCS  (NATO  General  Purpose  Communication  System).  The  Joint 
Warfare  Centre  (JWC)  and  Joint  Forces  Training  Centre  (JFTC)  provide  the  backbone  infrastructure  by  hosting 
the  core  services  and  functionality  for  each  NATO  Snow  Leopard  component.  JWC  and  JFTC  core  capability 
must  be  easily  extendable  and  reconfigurable  to  reach  and  provide  services  to  NATO  HQs,  Centres  Of 
Excellence  (COE),  NATO  Schools,  governmental  and  non-governmental  agencies  and  appropriate  national 
centres,  ranges,  or  virtual  simulators,  depending  upon  exercise  specifications  and  National  needs  and  desires. 
NATO  Snow  Leopard  instituted  a  common  set  of  standards,  protocols,  interface  middleware  and  procedures 
for  M&S,  C4ISR  and  live  systems  integration.  These  establish  the  foundation  for  NATO-wide  interoperability 
and  reuse  in  the  training  and  education  domain.  The  education  component  capitalizes  on  the  latest  web 
enabled  technologies  for  Advance  Distributed  Learning  (ADL).  A  scenario  management  framework  allows  rapid 
scenario  generation  and  sharing  in  a  collaborative  environment  while  enforcing  version  control,  user  access 
rights  and  retrieve  and  storage  mechanisms. 

NATO  Snow  Leopard  was  planned  to  be  a  multi-year  phased  program.  The  NATO  Snow  Leopard  NATO 
Training  Federation  (NTF)  met  Initial  Operational  Capability  (IOC)  in  2008  by  supporting  Steadfast  Joiner  08. 
In  this  exercise,  JWC  hosted  a  distributed,  multi-level  NATO  Response  Force  (NRF)  Computer-Assisted 
Exercise  (CAX).  The  NATO  Live,  Virtual  and  Constructive  (NLVC)  federation  infrastructure  met  IOC  in  2010 
during  the  MSG-068  Stand  Alone  Experiment  (SAE).  NATO  Snow  Leopard  Full  Operational  Capability  (FOC) 
was  expected  in  2011  -  2012  timeframe.  It  was  also  expected  that  NATO  Snow  Leopard  would  demonstrate 
FOC  by  supporting  a  NATO  event,  meanwhile  NETN  development  will  continue  to  support  operational 
requirements  through  a  dynamic,  evolving  environment  to  provide  flexibility  and  promote  reusability. 
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In  2010,  ACT  changed  the  Snow  Leopard  Program  name  to  Distributed  Training  and  Exercises  (DTE)  to  more 
clearly  identify  the  program’s  purpose.  DTE  will  progressively  expand  to  capitalize  on  emerging  technologies 
and  include  other  NATO  and  Partner  Nations  as  they  acquire  new  capabilities.  A  fully  operational,  networked 
education  and  training  capability  lead  by  Headquarters,  Allied  Command  Transformation  (HQ  ACT)  and 
centered  at  the  Joint  Warfare  Centre  (JWC),  Joint  Forces  Training  Centre  (JFTC)  and  NATO  School  will 
allow  NATO  to  distribute  training  and  exercises  across  Alliance  education  and  training  centres,  while  at  the 
same  time  enabling  those  forces  to  train  together  using  the  same  key  decision  points  and  objectives  necessary 
to  make  the  NRF,  CJTF,  ISAF  staffs  and  assigned  forces  ready  to  deploy. 

NATO’s  transformation  process  builds  on  education  and  training  by  developing  and  inoculating  interoperability, 
especially  through  linking  NATO  and  national  systems,  forces  and  headquarters  -  and  routinely  practicing  and 
refining  tactics,  techniques,  and  procedures  to  meet  the  evolving  operational  requirements.  NATO  DTE  is  a 
critical  element  of  that  solution  set  and  will  bring  education  and  training  to  those  who  need  it  anywhere  at 
anytime  and  will  transform  NATO  intellectually,  culturally  and  militarily. 

Upon  request  by  HQ-SACT,  NMSG  formed  MSG-068  NETN  to  support  NATO’s  DTE  vision.  Many  of  the 
previous  experiences  and  products  from  NMSG  activities,  such  as,  MSG-027  (Pathfinder  Integration 
Environment),  MSG-001  (Exercise  First  WAVE),  MSG-052  (Knowledge  Network  for  Federation 
Architecture  and  Design),  as  well  as  from  national  and  NATO  distributed  simulation  events,  established 
the  starting  conditions  for  MSG-068.  In  particular,  MSG-001  (Exercise  First  WAVE),  set  the  standard  for 
MSG-068.  MSG-001  and  the  NATO  SAS-034  Task  Group  collaborated  in  a  joint  project  executed  between 
2000  -  2004  to  develop  a  prototype  NATO  synthetic  Mission  Training  through  Distributed  Simulation 
(MTDS)  environment  to  support  a  multi-national  exercise  and  assess  its  potential  to  support  training  to 
enhance  NATO’s  operational  effectiveness  in  multi-national  air  operations.  This  7-nation  activity  (CAN, 
DEU,  FRA,  GBR,  ITA,  NLD,  USA)  was  known  as  “Exercise  First  WAVE”  (Warfighter  Alliance  in  a  Virtual 
Environment),  the  first  large  simulation-based  aircrew  training  exercise  organised  in  NATO.  The  exercise 
explored  issues  of  matching  training  requirements  and  technical  capability  and  exposed  the  need  for  a  multi¬ 
national  exercise  development  team  to  address  both  these  aspects.  This  experiment  used  DIS  as  its  interoperability 
protocol  and  was  run  as  unclassified  event.  The  network  infrastructure  was  based  on  commercial  leased  lines  and 
was  dismantled  the  day  after  the  exercise  finished. 

In  compliance  with  STANAG  4603,  MSG-068  selected  the  High-Level  Architecture  (HLA)  as  the  technology 
for  integration  and  interoperability  between  simulation  assets.  Specifically,  MSG-068  focused  on  HLA-evolved, 
which  became  IEEE  standard  1516-2010  during  the  MSG-068  tenure,  and  one  feature  of  IEEE  1516-2010, 
FOM  modularity,  was  a  key  element  in  achieving  the  desired  flexibility  and  maintainability  level. 

2.0  OBJECTIVES 

The  objective  of  the  MSG-068  NETN  Task  Group  is  to  assess  the  distributed  simulation  and  learning 
capabilities  that  NATO,  Partner  and  Contact  Nations,  Schools,  and  Agencies  have  that  could  contribute  to  the 
development  of  a  NETN  capability.  The  Task  Group  (TG)  also  recommends  and  demonstrates  a  way  forward 
for  interoperability,  technical  standards  and  architectures  to  link  these  training  and  education  centres  to 
provide  a  shared  persistent  capability.  Finally,  the  TG  identifies  and  recommends  roles  and  responsibilities  of 
the  NATO,  Partner  and  Contact  Nation  organizations  responsible  for  distributing  and  maintaining  M&S 
capabilities  within  the  scope  of  NETN. 

The  following  topics  were  covered  under  this  TG  to  meet  the  objectives: 

•  Assessment  of  distributed  simulation  and  learning  capabilities  with  potential  for  inclusion  in  NETN. 
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•  Recommendations  for  interoperability  and  technical  standards. 

•  Recommendations  for  the  development  of  NETN  architectures. 

•  Recommendations  for  the  assignment  of  roles  and  responsibilities  for  distributing,  managing  and 
maintaining  NETN  capabilities. 

•  Identify,  develop  and  conduct  experiments  enabling  NATO/PfP  Nation’s  capabilities  to  participate  in 
NETN. 

•  Roadmaps  and  technical  reports  in  support  of  NETN. 

•  Demonstration  of  a  limited  NETN  realization  comprising  JWC,  JFTC  and  national  simulation  centres 
and  systems. 

•  Run  preparatory  tests  at  ACT  and  national  facilities  and  evaluate  the  results  from  these  tests  for  risk 
reduction  of  the  demonstration  of  the  feasibility  of  the  NETN-concept. 

•  Perform  a  demonstration  of  the  feasibility  of  the  NETN  concept  of  a  distributed  networked  training 
capability  embracing  JWC,  JFTC  and  national  simulation  centre  and  the  corresponding  simulators, 
simulation  systems  and  C2-systems. 


3.0  THE  REQUIREMENTS  FOR  NETN 

Over  the  last  decade  the  world’s  strategic  geopolitics  have  changed  tremendously  and  NATO  as  a  central  key 
player  has  adapted  itself  to  the  new  realities: 

•  NATO  is  fully  committed  in  Afghanistan  with  some  30,000  troops  conducting  warfighting  activities 
in  certain  areas. 

•  As  part  of  the  NRF  concept,  NATO  might  deploy  a  multi-national  force  out  of  Europe  within  a  few 
weeks. 

When  NATO  forces  are  deployed  in  theatre  to  conduct  a  joint  operation,  all  forces  from  the  Joint  HQ  down  to 
the  unit  in  the  theatre  of  operation  have  to  be  trained  on  the  specificities  of  the  mission  within  a  reduced  time 
frame,  typically  less  than  9  weeks.  Depending  on  the  command  level  of  the  force,  the  training  is  a  NATO  or  a 
national  responsibility  and  the  most  relevant  vehicle  of  the  training  is  different:  aggregated  constructive 
simulation,  high  resolution  constructive  simulation,  virtual  simulation  and/or  live  simulation.  Each  type  of 
simulation  provides  the  details  required  to  portray  an  operation  at  the  appropriate  resolution  and  to  feed  C2 
information  systems  in  a  realistic  manner. 

In  addition,  the  technology  evolution  over  the  last  few  years  in  the  fields  of  communication  systems,  information 
sharing  and  multi-media  means  has  impacted  the  way  military  forces  are  managing  crises.  New  concepts  such  as 
Network  Centric  Warfare  and  Time  Sensitive  Targeting  are  using  those  technologies  as  a  force  multiplier  by 
tying  force  components  tightly  together  and  reducing  decision  cycle  processes.  NETN  should  provide  a  solution 
at  the  NATO  level  to  the  challenging  requirement  of  training  a  joint  multi-national  force  in  managing  crises  in 
this  new  era  of  warfare. 

In  this  section  we  examine  why  NETN  is  needed  and  how  it  can  serve  this  purpose.  To  do  this  we  answer 
three  questions,  which  appear  as  section  headings  of  the  section. 
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Training  Requirements 


Snow  Leopard 


♦  \ 


1  Provide  joint  operational  level  training 
for  NRF,  CJTF  and  NATO  HQs 
deploying  on  operations  (MRT),  at  JWC 
2Provide  joint  tactical  level  training  for 
Component  Command  HQs  level  and 
down  through  organically  assigned 
tactical  command  elements,  at  JFTC. 

MCM-214-03,  “JJJ  Missions,  Roles  And 
Relationship”,  13  Nov  2003;  MC  510,  “Terms  Of 
Reference  For  JJJ  Directors”,  30  Apr  2004;  ACT 
Directive  80-3,  “Operating  Requirements  For  JJJ”, 
10  Mar  04 


•Natl  Sim  Centers 
•Natl  Simulators 
•Natl  Training  Ranges 


♦♦  J 


3. 1  nteroperabi I  ity  between  NATO  and 
national  LVC  capabilities  in  order  to 
create  a  blended  training  environment 

DCOS-T  Guidance;  NETN  Vision;  SACT'  Top 
Priorities 


*  The  term  “Nations  ”  refers  both  to  NATO  and  Partner  Nations. 


Figure  1:  Training  Requirements. 


3.1  Why  Do  NATO  and  Nations  Need  Multi-Level  and  Cross-Level  Training? 

NATO  has  a  joint,  multi-level  command  structure  that  needs  to  operate  together.  This  necessitates  multi-level 
and/or  cross-level  training.  When  multi-  and/or  cross-level  training  is  conducted  there  may  be  parts  of  a  Training 
Audience  (TA)  that  have  a  set  of  training  objectives  different  from  the  other  parts  of  the  TA.  For  example  the 
training  objectives  of  a  maritime  component  command  may  be  different  from  the  ones  for  a  JFC  that  joins  the 
same  exercise.  If  the  training  objectives  are  determined  with  a  focus  on  a  part  of  the  TA,  then  the  overall 
exercise  is  designed  accordingly,  which  means  the  exercise  may  not  fulfil  the  requirements  of  all  of  the  TA. 
New  multi-resolution  exercise  methodologies,  constructs  and  technologies  are  needed  to  ensure  all  TA 
training  objectives  are  met  in  the  face  of  the  following  challenges: 

•  The  training  objectives  of  echelons  differ  from  each  other. 

•  There  is  a  need  to  conduct  an  exercise  in  an  overarching  environment  providing  the  possibility  of  high 
detailed  realistic  information. 

•  There  is  a  need  to  practice  information  flow  among  the  echelons. 
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•  The  decision  cycles  of  forces  deployed  in  theater  are  interdependent. 

•  The  combined  and  joint  nature  of  force  structures  has  been  increased. 

•  Most  operations  are  conducted  by  diverse  force  elements  that  must  work  synergistically  at  all  levels, 
from  strategic  down  to  tactical  levels. 

Despite  those  challenges,  NATO  anticipates  the  following  benefits: 

•  Combining  training  events  into  a  reduced  number  of  multi/cross-levels  training  events  yields  efficiencies 
and  reduces  costs. 

•  Multi-  and  cross-level  training  can  provide  dynamic,  capability  based  training  across  a  full  range  of 
integrated  operations  between  NATO  forces,  member  forces,  and  partner  forces. 

•  If  the  Nations  train  as  they  fight,  both  on  the  strategic  and  tactical  level,  then  they  will  learn  to  operate 
as  a  cohesive  force. 

3.2  Why  Do  NATO  and  Nations  Need  LVC? 

Training  audiences  should  be  immersed  in  a  realistic  environment  and  situation  that  can  be  consistently 
maintained  throughout  the  exercise.  Constructive  systems  adequately  simulate  most  theatre  assets,  but  live  and 
virtual  systems  are  increasingly  necessary  to  more  accurately  represent  special  assets  present  in  current 
operational  environments  or  to  emulate  C4ISR  feeds  available  to  Warfighters.  For  example,  increasing  use  of 
UAVs  in  theatre  has  led  to  not  only  more  detailed  representation  of  UAV  platforms  in  simulation  environments, 
but  the  need  to  provide  video  feeds  to  training  audiences  expecting  similar  capabilities  in  theatre.  All  the 
components  of  this  synthetic  world  must  work  together  cohesively  in  order  to  achieve  the  training  promises 
afforded  by  multi-resolution  and  LVC  capabilities: 

•  True  multi-level  and  cross-level  training  can  only  be  achieved  through  LVC. 

•  LVC  will  support  a  broad  spectrum  of  joint  training  requirements. 

•  LVC  provides  the  capability  to  conduct  coherent  joint  training  across  different  levels  of  TA, 
and  hence  it  will  provide  a  seamless  and  more  realistic  training  environment. 

•  NATO  may  need  LVC  to  support  exercises  that  include  NATO-owned  platforms,  e.g.,  AWACS  or 
specific  nationally  provided  platforms  that  require  specific  interoperability  measures. 

•  LVC  training  is  required  to  achieve  the  necessary  immersion  of  decision  makers. 

•  LVC  simulation  systems  are  needed  to  standardize  preparation  for  operations  in  an  international 
environment;  to  reduce  health  and  material  risk;  to  make  better  use  of  resources  (efficiency  and 
effectiveness);  to  compensate  for  restrictions  (e.g.,  environment  protection,  access  to  scarce  resources 
by  replacing  them  with  simulated  assets). 

•  The  LVC  will  allow  Nations  to  participate  in  a  full  spectrum  training  environment  providing  combined 
task  force  commanders  and  staffs  a  cost  effective  way  to  fully  train  disparate  national  forces  into  a 
cohesive  fighting  force. 

3.3  What  Are  the  Benefits  of  NETN  for  NATO  and  Nations? 

We  can  summarize  the  benefits  of  NETN  for  NATO  and  Nations  as  follows: 
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For  NATO: 

•  NETN  will  reduce  the  educational  and  training  costs  for  all  participants. 

•  NETN  will  improve  the  interoperability  among  all  participants  (NATO,  Members  and  Partners). 

•  The  NETN  will  be  a  persistent  global  network  of  live,  virtual  and  constructive  components,  to  include 
collaborative  tools  and  services  that  provide  a  seamless  training  environment  that  supports  a  broad 
spectrum  of  NATO  and  Nations  training  requirements. 

•  It  will  support  coherent  training  across  different  levels  of  TA,  and  it  will  provide  a  seamless  and  more 
realistic  training  environment.  Moreover,  it  will  deliver  to  the  Alliance  and  Partners  a  distributed 
Education  and  Training  Capability  that  will  comprise  distance  learning  and  shared  scenarios  database 
capability. 

•  NETN  will  provide  NATO  and  the  Nations  with  the  means  to  plan,  conduct  and  control  a  comprehensive 
building  block  approach  to  the  training  of  a  multi-national  force  in  the  context  of  a  common  scenario  and 
with  a  coordinated  approach  to  training  design  and  observation. 

•  NETN  will  improve  the  exercise  quality  and  efficiency. 

•  Nations  will  have  a  better  understanding  of  NATO’s  role  and  how  to  interact  with  NATO  as  well  as 
ensure  national  forces  are  ready  to  conduct  NATO  operations  in  a  coalition  force  structure. 

•  NETN  will  help  to  achieve  better  effects  through  standardization,  reduced  cost,  resource  savings, 
and  certified  units. 

•  Better  and  less  expensive  possibilities  to  do  mission  rehearsal. 

For  Nations: 

•  Nations  can  conduct  mission  rehearsal  with  others  (NATO/Nations)  before  going  to  mission  (Train  as 
you  fight). 

•  NETN  will  reduce  the  cost  for  establishing  training  and  experimentation  networks. 

•  NETN  will  help  to  improve  communications  and  exchange  of  experience  among  NATO  Members. 
This  is  an  excellent  opportunity  for  education  and  training. 

•  NETN  will  provide  means  for  cooperation  between  NATO  HQ’s,  national  HQ’s  and  other  members 
forces  HQ’s  and  units  in  collectively  distributed  LVC  environments. 

•  NETN  will  improve  interoperability  between  simulated  or  emulated  national  C2  systems  in  the  NATO 
simulation  environment. 

•  NETN  will  improve  interoperability  between  NATO  and  national  LVC. 

•  Nations  will  be  able  to  access  to  standardized  scenarios  and  geo-databases. 

•  Nations  will  be  able  to  access  to  unified  ADL  content. 

•  Nations  will  be  able  to  access  to  key  technologies,  technical  standards  and  advance  architectures  for 
distributed  LVC  environments. 

•  Nations  will  be  able  to  develop  interfaces  between  national  LVC  systems  and  NTF. 

•  Nations  will  learn  from  experiments  enabling  new  services  for  NETN. 
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•  Nations  will  benefit  from  the  improved  environment  NETN  offers  for  crisis  management  training  and 
education  for  civilian  responding  entities. 

•  Nations  will  benefit  from  the  opportunities  NETN  provides  for  technology  research,  learning,  innovation 
and  business  opportunities  for  SMEs  and  research  organizations. 


4.0  ASSESSMENT  OF  DISTRIBUTED  SIMULATION  AND  LEARNING 
CAPABILITIES 

MSG-068  conducted  a  survey  to  assess  interest  in  NETN  capabilities.  The  following  questions  were  answered 
by  Nations  and  organizations: 

•  Which  Nations  would  like  to  join  NETN? 

•  Which  simulation  centres  would  the  Nations  like  to  utilize  for  NETN? 

•  Which  simulation  systems,  C2  systems,  CIS  systems,  architectures,  environments  and  tools  are  in  use 
and  will  be  in  use  in  these  simulation  centres? 

•  What  are  the  future  developments  that  will  impact  NETN  and  Nations  capabilities? 

•  What  is  the  Nation’s  level  of  commitment  to  adopt  NETN? 

The  following  Nations  are  interested  in  NETN  and  have  simulation  centres  that  can  participate  in  NETN: 
Australia,  Belgium,  Bulgaria,  France,  Germany,  Italy,  Netherlands,  Norway,  Romania,  Slovenia,  Spain,  Sweden, 
Turkey,  UK,  USA. 

There  are  many  varied  and  numerous  simulation  and  C2  systems  that  Nations  use  and  which  any  NETN 
architecture  would  need  to  accommodate.  Nations  and  organizations  use  different  architectures  and  standards 
for  constructing  training  and  learning  environments.  Our  findings  in  the  survey  can  be  summarized  as  follows: 

•  More  joint  and  system-of-sy stems  environments  are  required. 

•  National  training  networks  should  be  integrated  in  NETN. 

•  Different  architectures  (mixed  architectures,  e.g.,  DIS  and  HLA),  RTIs  and  federation  agreements 
need  to  be  integrated. 

•  Integration  of  COTS  and  live  assets  is  also  needed. 

In  general,  the  Nations  which  responded  are  committed  to  the  NETN  approach.  This  is  corroborated  by  the 
following  Nations  which  participated  in  MSG-068  and  contributed  in  order  to  develop  and  demonstrate  the 
feasibility  of  the  NETN  approach:  Australia,  Bulgaria,  France,  Germany,  Hungary,  Netherlands,  Romania, 
Spain,  Turkey,  UK,  USA. 


5.0  RECOMMENDATIONS  FOR  INTEROPERABILITY  AND  TECHNICAL 
STANDARD 

In  order  to  achieve  interoperability  and  rapid  integration  of  simulation  systems,  MSG-068  developed  a  baseline 
NETN  Reference  Architecture.  This  architecture  is  defined  in  terms  of  a  persistent  infrastructure,  federation 
agreements,  shared  resources,  and  common  tool  sets. 
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5.1  Persistent  Infrastructure 

Although  NATO  and  Nations  conducted  geographically  distributed  CAXs  in  the  past,  these  used  infrastructure 
that  had  to  be  re-established  for  every  exercise.  That  proved  costly  and  unresponsive.  Technological  advances 
suggest  more  cost  effective,  responsive,  and  efficient  means  to  support  current  and  future  training  requirements. 
MSG-068  established  an  infrastructure  sub-group  to  investigate  a  number  of  options  for  a  more  persistent  and 
cost  effective  infrastructure  approach.  This  MSG-068  sub-group  consisted  of  15+  experts  that  worked 
collaboratively  to  develop  the  recommendations  summarized  below.  The  research  results  and  recommendations 
with  respect  to  the  NETN  persistent  infrastructure  are  detailed  in  Annex  C  and  E. 


5.1.1  Exercises  Requiring  a  Secure  Infrastructure 

MSG-068  recommends  the  Combined  Federated  Battle  Laboratories  Network  (CFBLNet)  as  the  persistent 
backbone  for  NETN  up  to  NATO  SECRET.  CFBLNet  provides  secure  and  managed  services  over  a  bearer 
network.  Persistent  in  this  context  means  services  are  provided  with  a  guaranteed  network  availability  and 
quality  of  service.  The  CFBLNet  architecture  allows  users  to  create  enclaves  with  various  classification  levels 
up  to  NATO  Secret.  An  enclave  can  only  have  a  single  level  of  security  classification  at  a  time.  However, 
the  security  classification  of  an  enclave  can  be  changed  from  one  event  to  the  other.  A  CFBLNet  enclave  may 
also  be  accessible  by  Partnership  for  Peace  (PfP),  Mediterranean  Dialog  (MedDialog),  Istanbul  Cooperation 
Initiative  (ICI),  Contact  Nations,  and  the  other  Nations  when  the  security  classification  of  the  enclave  is 
established  to  allow  these  participants.  The  Nations  may  extend  the  CFBLNet  to  include  their  own  training  sites 
or,  alternatively,  connect  the  national  CFBLNet  Point-of-Presence  (PoP)  to  a  national  secure  network 
infrastructure.  Notwithstanding  the  recommendation  to  use  CFBLNet,  MSG-068  found  several  issues  which 
require  improvement: 

•  The  procedures  for  joining  CFBLNet  or  extending  an  existing  PoP  should  be  simplified  and  clarified. 

•  When  CFBLNet  is  used,  it  introduces  another  technical  management  level  on  top  of  the  technical 
administration  of  the  bearer  networks.  The  user  needs  to  manage  these  two  layers  separately  for 
multiple  sites,  which  is  not  always  practical.  A  scheme  to  unify  the  management  of  infrastructure 
(i.e.,  to  provide  single  point  of  contact  for  the  infrastructure)  needs  to  be  developed. 

5.1.2  Unclassified  Exercises 

Not  all  exercises  require  the  services  for  security  and  management  provided  by  CFBLNet  together  with  its 
attendant  overhead  and  cost.  It  is  possible  to  operate  NETN  federations  over  the  Internet  when  the  services 
provided  by  CFBLNet  are  not  required.  VPN  over  the  internet  may  provide  sufficient  security  or  information 
protection  for  many  events.  The  selection  between  the  persistent  CFBLNet  solution  and  semi-persistent 
solutions  like  the  Internet  depends  on  the  frequency  of  need  for  a  classified  (CFBLNet)  capability.  However, 
even  Nations  or  organizations  with  infrequent  classified  event  requirements  may  find  that  CFBLNet  has  a 
cost-benefit  advantage  in  avoiding  the  engineering  time  in  installing  and  closing  networks  and  in  the  higher 
user  fees  paid  for  temporary  installation. 


5.1.3  Multi-Level  Security  Domains 

MSG-068  did  not  have  time  or  resources  to  investigate  multi-level  security  or  cross-domain  information 
exchange.  Clearly  this  field  is  of  interest  and  importance  due  to  the  mix  of  organizations,  NATO,  PfP,  NGO,  etc., 
and  consequent  need  for  improved  policies  and  tools  for  information  exchange.  MSG-068  recommends  better, 
more  reliable,  robust  and  practical  multi-level  security  protocols  and  procedures.  This  topic  is  currently  addressed 
by  on-going  NMSG  studies,  notably  MSG-080,  Security  in  Collective  Mission  Simulation. 
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5.2  NETN  Federation  Architecture  and  FOM  Agreement 

A  MSG-068  Federation  Architecture  and  FOM  Design  (FAFD)  technical  sub-group  was  created  with  70+ 
representatives  from  the  participating  NATO  and  Partner  Nations  and  organizations. 

The  purpose  of  the  group  was  to  develop  a  Federation  Agreements  and  FOM  Design  Reference  Document 
that  will  support  the  initial  NETN  Reference  Architecture  for  NATO  and  the  Nations. 

The  document  provides  a  common  reference  Federation  Agreements  Document  (FAD)  for  all  federations  in  the 
NATO  Education  and  Training  Network  (NETN)  including  a  modular  FOM  with  detailed  information  on  data 
and  information  exchange  between  simulation  systems  in  an  NETN  federation.  The  FAD  and  FOM  are  designed 
to  be  generic  and  can  be  used  for  live,  virtual,  constructive  and  multi-resolution  federations  at  any  level. 

The  FAFD  group  represents  a  broad  community  of  practice  with  respect  to  federation  architecture  and  design. 
Major  systems,  federations  and  training  networks  were  represented  in  the  FAFD  group.  The  input  provided  and 
the  harmonization  of  federation  architecture  and  design  agreements  forms  the  basis  of  the  NETN  Federation 
Agreements  and  FOM  Design  Reference  Document. 

Key  input  to  the  development  of  the  federation  agreements  includes: 

•  ALLIANCE  (France); 

•  CASIOPEA  (Spain); 

•  JLVC  (USA); 

•  JMRM  (US  and  JWC); 

•  KOSI  (Germany); 

•  NLVC  (NC3A,  Netherlands); 

•  P2SN  (Sweden);  and 

•  RPR-FOM  v2.0  (SISO). 

The  recommendations  from  the  MSG-068  FAFD  sub-group  are  summarized  below: 

•  In  compliance  with  STANAG  4603  [9],  MSG-068  recommends  that  the  backbone  of  any  NATO 
simulation  federation  is  the  latest  version  of  the  High-Level  Architecture  (HLA).  IEEE  1516-2010  is 
the  current  HLA  version  and  provides  services  and  concepts  that  enable  flexible  and  modular  FOM 
development  (see  Figure  2). 

•  The  Simulation  Interoperability  Standards  Organization  (SISO)  has  defined  the  Real-time  Platform 
Reference  FOM  (RPR-FOM).  MSG-068  recommends  the  SISO  standard  RPR-FOM  v2.0  to  represent 
ground-truth  of  platform  and  aggregate  level  simulated  entities.  The  RPR-FOM  object  classes  are  extended 
with  more  detail  in  the  NETN  Aggregate  Unit  FOM  Module. 

•  MSG-068  recommends  the  SISO  standard  Link  16  BOM  for  simulation  of  Linkl6  messages. 
This  module  also  extends  the  RPR-FOM. 

•  MSG-068  recommends  a  new  NETN  Service  Consumer-Provide  FOM  Module  for  modeling  request, 
negotiation  and  delivery  of  services  (see  Annex  C).  This  FOM  module  does  not  extend  any  other 
FOM  module.  The  Service  Consumer-Provider  Pattern  defines  two  types  of  entities: 
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•  Service  Consumer  Entities;  and 

•  Service  Provider  Entities. 

Similarly  federates  that  model  these  entities  are  called  Service  Consumer  Federates  and  Service 
Provider  Federates,  respectively.  If  service  entities  are  modeled  in  different  federates  the  interactions 
will  be  published  and  subscribed  using  HLA  services. 

•  MSG-068  recommends  a  new  NETN  Aggregate  Unit  FOM  Module.  This  module  is  based  on  the 
Service  Consumer-Provider  Pattern  with  extensions  to  support  aggregate  and  entity  object  attributes 
not  contained  in  the  RPR  FOM.  The  NETN  Aggregate  Unit  FOM  Module  also  includes  provisions  for 
a  combat  adjudication  service;  this  service  will  be  addressed  in  further  detail  below. 

•  MSG-068  recommends  a  new  NETN  Fogistics  FOM  Module.  This  module  is  based  on  the  Service 
Consumer-Provider  Pattern  with  extensions  to  support  the  following  specific  logistics  services: 

•  Supply; 

•  Storage; 

•  Repair; 

•  Transport; 

•  Embarkment;  and 

•  Disembarkment. 

•  The  FAFD  sub-group  identified  additional  FOM  Modules  and  also  conducted  some  preliminary  work 
on  these.  Due  to  time  constraints  and  priorities  these  modules  have  not  be  finalized  and  verified  in 
experimentation.  The  FAFD  sub-group  recommends  that  future  work  will  continue  to  investigate  and 
experiment  with  these  modules  in  order  to  have  them  included  in  future  versions  of  the  FAD  and 
FOM.  These  modules  are:  Federation  Execution  Control  and  Monitoring  and  Transfer  of  Modeling 
Responsibility. 

•  The  FAFD  sub-group  identified  additional  IEEE  1516-2010  features  that  the  team  was  unable  to 
implement  and  test  due  to  time  constraints.  The  FAFD  sub-group  recommends  future  development 
and  testing  of  smart  update  rate  reduction,  fault  tolerance,  Data  Distribution  Services  as  an  enabler  of 
scalability,  web  services,  etc. 

•  The  FAFD  sub-group  caveats  the  above  recommendations  by  acknowledging  that: 

•  FAFD  did  not  implement  or  test  the  combat  adjudication  service  or  Combat  Adjudication  Service 
Federate  (CASF)  described  in  the  NETN  Aggregate  Unit  FAD.  The  FAFD  sub-group  recommends 
future  development  of  a  CASF  to  evaluate  the  CASF  FAD  and  FOM  constructs.  FAFD  anticipates 
iterative  development  and  testing  of  the  CASF  and  FAD  and  FOM  constructs  will  be  required 
before  the  combat  adjudication  service  can  be  recommended  for  inclusion  in  the  MSG-068 
Reference  Federation  Architecture. 

•  FAFD  did  not  test  the  SISO  standard  Fink  16  BOM.  The  FAFD  sub-group  recommends  future 
testing  of  the  Fink  16  BOM  to  evaluate  its  sufficiency  for  DTE  use. 

•  FAFD  used  only  a  sub-set  of  the  object  classes  and  interactions  comprising  the  RPR  FOM. 
The  FAFD  sub-group  therefore  recommends  modularizing  the  RPR  FOM  in  accordance  with 
IEEE  1516-2010  FOM  modularity  principles. 
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•  FAFD  used  and  tested  only  a  sub-set  of  the  NETN  Logistics  FOM  Module  services.  In  the 
process  of  developing,  testing,  and  assessing  the  NETN  Logistics  FOM  Module,  the  FAFD  sub¬ 
group  concluded  that  it  is  unnecessarily  monolithic  and  therefore  recommends  modularizing  it  in 
accordance  with  IEEE  1516-2010  FOM  modularity  principles. 


NETN 

Logistics 


NETN  Aggregate 
Unit 


Link  16 
BOM 


Federation  Execution 
Control  and  Monitoring 


NETN  Service 

Real-time  Platform  Reference  (RPR)  -  Federation 

Consumer-Provider 

Object  Model  (FOM) 

Version  2.0 

Transfer  of 
Modeling 
Responsibilities 


Figure  2:  Modular  FOMs  Recommended  for  MSG-068  Reference  Federation  Architecture 
(Modules  with  dashed  frame  require  additional  work  before  inclusion  in  the  FAFD). 

The  complete  NETN  Federation  Architecture  and  FOM  Reference  Document  can  be  found  in  Annex  C. 

5.3  Shared  Resources 

MSG-068  did  not  directly  address  shared  resources.  However,  a  separate  study  by  HQ-SACT  [11]  has  addressed 
shared  scenarios.  The  most  important  findings  of  the  shared  scenarios  study  are  summarized  below: 

•  The  primary  existing  capability  to  share  NATO  produced  operational  level  Scenarios  and  Settings 
(S&S)  is  provided  by  the  Joint  Warfare  Center.  This  capability  includes  geo  databases,  the  geo¬ 
strategic  narrative  situation,  theatre  of  operations  information,  strategic  initiation  documents,  crises 
response  planning  information,  force  activations  and  deployment  information,  main  event  and  master 
incident  lists  (i.e.,  Joint  Exercise  Management  Module  databases)  and  simulation  databases  (i.e.,  Joint 
Theater  Level  Simulation  and  Virtual  Battle  Space  databases).  However,  this  capability  is  based  on  a 
manual  process,  limited  to  NATO  headquarters  and  Nations,  and  has  issues  related  to  IT  infrastructure. 

•  The  premise  that  NATO  HQs,  Nations  and  non-NATO  users  would  wish  to  re-use  JWC  S&S  material 
remains  to  be  proven.  However,  many  organizations  that  use  JWC-produced  S&S  for  their  internal 
exercises  do  not  understand  how  to  adapt  material  to  suit  their  own  training  objectives  and  spend 
considerable  effort  trying  to  achieve  this. 

•  There  exists  a  NATO  Simulation  Resource  Library  (NSRL)  [20]).  This  existing  capability  needs  to  be 
further  improved  such  that  it  can  allow  the  submission  of  new  S&S  meta  data  (i.e.,  information  about 
the  scenarios  and  scenario  modules)  and  the  access  by  a  wider  community.  A  prototype  has  been 
prepared  for  this  purpose  and  tested  during  MSG-068  NETN  Standalone  Experiment. 

•  Collaborative  ways  of  working  based  on  Web  2.0  technologies  should  be  considered. 

In  addition  to  the  study,  MSG-068  identifies  the  need  for  standard  taxonomy,  terminology  and  data  formats  for 
the  reusability  of  settings,  scenarios  and  scenario  modules.  There  are  already  standards  and  directives  for  this 
purpose,  such  as,  Military  Scenario  Definition  Language  (MSDL),  Bi-SC  Collective  Training  and  Exercise 
Directive  75-3,  C2  Information  Exchange  Data  Model  (C2IEDM),  etc.  The  use  of  the  above  mentioned 
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standards  is  recommended  in  the  NATO  Allied  M&S  Standards  Profile  AMSP-01  [19].  However,  all  these  can 
support  only  a  sub-set  of  the  shared  scenario  requirements. 

In  mid-tenure,  MSG-068  evaluated  using  unique  identifiers  and  the  Joint  Training  Data  Services  (JTDS) 
Order  of  Battle  Service  (OBS)  to  provide  scenario  initialization  information  to  all  NETN  federates.  Providing 
common  scenario  initialization  information  to  all  federates  enables  data  correlation  among  federates  and 
reduces,  if  not  precludes,  instances  of  data  mapping  errors.  While  MSG-068  was,  in  the  end,  unable  to  make 
use  of  OBS,  and  consequently  suffered  numerous  data  mapping  errors  during  the  experiment,  the  NETN  FOM 
does  include  provision  for  use  of  a  unique  identifier  for  each  object  instance.  Evaluating  these  identifiers  and  a 
scenario  initialization  service  must  necessarily  devolve  to  another  NMSG,  but  MSG-068 ’s  experimental 
results  clearly  indicate  the  criticality  of  a  comprehensive  data  strategy,  particularly  given  the  diverse  systems 
envisioned  for  use  in  NETN. 

5.4  Common  Tools 

In  order  to  enable  interoperability  and  the  use  of  the  infrastructure  for  events,  we  recommend  the  following 
key  common  tools: 

•  CIS:  Collaborative  tools  are  essential  to  support  the  development  of  Federation  Agreements  and  to 
support  test  and  integration.  MSG-068  used  a  Wiki-based  Collaborative  Work  Environment  (CWE)  as 
recommended  by  MSG-052.  Telephone  and  video  conferences  were  conducted  using  regular  phones 
and  Skype.  In  order  to  have  a  common  tool  for  visualization  of  the  simulation  data  Google  Earth 
together  with  the  tool  Pitch  GE  Adapter  was  used.  The  simulation  voice  communications  application 
PLEXCOMM  was  provided  to  allow  users  to  role  play  various  actors  in  vignettes  and  coordinate 
technical  control  matters. 

•  Mixed  Architecture:  The  backbone  needs  to  be  the  latest  version  of  HLA.  However,  to  support 
legacy  and  COTS  simulation  systems  we  recommend  that  gateways  between  the  different  architectures 
should  be  allowed. 

•  Test  and  Integration:  MSG-068  established  an  experimentation  and  demonstration  sub-group  to 
provide  services  related  to  test  and  integration.  We  recommend  a  network  overlay  tool  to  simplify  the 
technical  set  up  for  test  and  integration.  In  MSG-068  we  used  the  Pitch  Booster  for  this  purpose. 

•  Exercise  and  Scenario  Management  Tools:  These  tools  can  be  used  for  the  automation  of  processes, 
information  management  and  information  exchange  throughout  an  exercise  process.  They  can  help  the 
preparation  and  management  of  scenario  as  well  as  the  Main  Event  and  Master  Incident  Lists  (MEL/ 
MIL).  A  MEL/MIL  tool  can  also  be  very  useful  in  synchronizing  and  managing  the  flow  of  an  exercise 
according  to  the  exercise  objectives,  as  well  as,  planning,  collecting  and  analyzing  the  observations.  In 
MSG-068  we  used  JEMM  (Joint  Exercise  Management  Module)  for  this  purpose. 

•  Patterns:  MSG-068  recommends  use  of  design  patterns  in  developing  FOM  modules  and  corresponding 
FADs.  Design  patterns  promote  reuse  by  abstracting  purpose  from  implementation.  MSG-068’s 
development  and  use  of  the  Consumer-Provider  design  pattern  exemplifies  this  abstraction  and  resultant 
reuse.  Defining  and  documenting  the  conceptual  relationship  between  a  consumer  and  provider  distinct 
from  the  specific  implementation  of  a  tanker  resupplying  fuel  or  maintenance  personnel  repairing  a 
truck,  enabled  specification  of  the  higher  level  key  actions  and  important  entities.  These  were  then 
reused  in  not  only  instances  of  resupply  or  repair,  but  other  situations,  e.g.,  the  “service”  provided  by 
a  Combat  Adjudication  Service  Federate  (CASF).  Design  patterns  complement  FOM  modularity, 
for  example,  the  Consumer-Provider  FOM  module  is  distinct  from  the  FOM  modules  supporting 
resupply  or  combat  adjudication. 
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•  FEDEP-DSEEP:  MSG-068  recommends  following  the  FEDEP  [10]  and  the  DSEEP  standards  to 
develop  the  NETN  simulation  federations  and  to  execute  the  training  and  exercise  events.  NMSG-068 
used  the  principles  of  FEDEP,  particularly  in  developing  the  federation  agreements  and  design,  and  in 
executing  the  experimentation  and  demonstrations. 

6.0  RECOMMENDATIONS  FOR  THE  DEVELOPMENT  OF  NETN 
ARCHITECTURES 

MSG-068  recommendations  are  not  complete  to  bridge  the  recommended  reference  architectures  and  operational 
processes  and  architectures.  To  fill  this  gap,  we  recommend  a  follow  on  technical  activity,  which  focuses  on 
the  operational  issues  related  to  NETN. 

6.1  Reference  Architecture 

The  NETN  Reference  Architecture  comprises  guidance  for: 

•  Persistent  Infrastructure; 

•  NETN  Federation  Architecture  and  FOM  Agreement; 

•  Shared  Resources;  and 

•  Common  Tools. 

The  NETN  Reference  Architecture  provides  the  foundation  for  developing  national  and  NATO  training 
networks  (NETN  Target  Architecture).  An  NETN  Target  Architecture  is  a  tailored  instantiation  of  the  NETN 
Reference  Architecture  for  a  (Target)  Exercise  Architecture. 

MSG-068  recommends  that  the  core  documents  in  the  NETN  reference  architecture  are  managed  by  NMSG. 
Nations  and  organizations  implementing  NETN  target  architectures  should  use  the  recommendations  provided 
by  this  group  and  provide  feedback  regarding  improvements  or  extensions  that  should  be  integrated  in 
the  reference  architecture  (e.g.,  new  FOM  modules).  Further  research  with  respect  to  extending  the  reference 
architecture  should  be  coordinated  by  a  persistent  NMSG  sub-group  in  charge  of  technical  guidance,  i.e.,  the 
M&S  Standards  Sub-group  (MS3). 

6.2  Exercise  Architecture 

Exercise  architecture  has  two  main  components:  Training  Audience  (TA)  and  Exercise  Control  staff  (EXCON). 
TA  is  the  focal  point  in  an  exercise  structure.  TA  can  be  single  level,  multi-level,  cross-level  and  both  cross- 
and  multi-level  as  shown  in  Figure  3: 

•  Single  level  training  audience  represents  a  single  level  of  command  trained  at  the  same  time  in  the 
context  of  a  single  scenario. 

•  Multi-level  training  audience  represents  multiple  levels  of  command  trained  at  the  same  time  in  the 
context  of  a  single  scenario. 

•  Cross-level  TA  includes  units  or  headquarters  at  the  same  level  of  command.  When  the  units  in  a  cross¬ 
level  TA  are  from  different  services,  the  exercise  becomes  joint. 

•  Multi-  and  cross-level  is  a  mix  between  multi-level  and  cross-level. 
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ORGANIZATION 


a.  Single  level 


c.  Cross-level 


a 


b.  Multi-level  d.  Multi-  and  Cross-level 

Figure  3:  Training  Audience. 


A  TA  can  have  Headquarters  (HQ)  and/or  forces  from  different  Nations,  which  makes  the  exercise  combined. 
In  more  and  more  exercises  civilian  national/intemational  agencies  and  organizations  like  police,  fire  department, 
health  agencies  and  UN  are  involved  in.  These  civilian  organizations  usually  become  a  part  of  EXCON  and 
constitute  white  or  grey  cell.  They  may  also  be  a  part  of  TA.  EXCON  structure  and  white/grey  cell  concept  is 
explained  later  in  this  section. 

TA  can  be  co-located  or  various  parts  of  TA  can  be  located  in  geographically  remote  sites  (i.e.,  different  cities, 
countries  or  continents).  The  exercises  that  have  TA  components  located  remote  sites  are  called  distributed 
exercises.  Please  note  that  distributed  simulation  means  different  from  distributed  exercise.  A  distributed  exercise 
can  be  supported  by  a  centralized  simulation  system  or  a  centralized  exercise  can  be  supported  by  a  distributed 
simulation. 

In  NETN,  TA  can  be  more  complex  than  a  typical  NATO  or  national  exercise,  such  as  the  following: 

•  TA  composed  of  HQs  or  forces  from  several  Nations  (any  composition  of  NATO,  PfP,  MedDialog, 
ICI,  contact  or  coalition)  without  a  NATO  HQ;  and 

•  TA  composed  of  HQs  or  forces  from  several  Nations  (any  composition  of  NATO,  PfP,  MedDialog, 
ICI,  contact  or  coalition)  with  a  NATO  HQ. 

The  other  component  in  an  NETN  exercise  structure  is  the  Exercise  Control  staff  (EXCON).  A  typical  EXCON 
structure  is  shown  in  Figure  4.  Training  Team  (TT)  consists  of  mentors,  Observer/Trainers  (O/T),  Subject-Matter 
Experts  (SME)  and  analysts.  TT  is  deployed  with  TA,  observe  TA,  provide  onsite  instructions  and  training,  and 
collects  inputs  for  AAR  and  the  evaluation  of  TA.  The  Exercise  Center  (EXCEN)  is  the  organization  responsible 
for  the  consistent  and  coherent  flow  of  the  exercise  according  to  the  Exercise  and  Training  Objectives  (ETO). 
EXCEN  is  explained  in  detail  below.  Experimentation  team  runs  the  experiments  planned  in  conjunction  with 
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the  exercise.  Finally  support  team  has  the  elements  like  Real-Life  Support  (RLS),  Visitor  Officer  Bureau  (VOB), 
Public  Information  Centre  (PIC),  security  office  and  computers/communications  support  team. 


Figure  4:  EXCON  Structure. 

EXCEN  functions  (see  Figure  5)  can  be  categorized  into  five  broad  classes  as  Control  Centre  (CONCEN), 
Higher  Control  (HICON),  Lower  Control  (LOCON),  white/grey  cell  and  Situation  Forces  (SITFOR).  CONCEN 
monitors  the  current  status  of  the  exercise  closely  and  steers  it  according  to  the  ETO.  HICON  and  LOCON 
represent  the  command  levels/echelons  that  would  normally  be  at  the  level  above  and  below  the  TA  respectively. 
LOCON  and  HICON  consist  of  Response  Cells  (RC).  The  number  of  RC  is  dependent  on  the  scenario  and  the 
TA.  Each  RC  is  made  up  of  a  number  of  planners,  a  number  of  simulation  operators  and  coordination  staff.  RC 
are  the  main  interface  between  simulation  and  exercise  as  explained  later  in  this  section.  White/grey  cell  is  a 
response  cell  that  is  composed  of  Subject-Matter  Experts  (SME)  or  role  players  representing  agencies, 
organizations,  institutions  and  individuals  outside  of  the  own  or  opposing  force  structure.  SITFOR  is  the  cell  that 
manages  the  status  of  all  the  own  and  opposing  forces  in  the  scenario  except  for  the  ones  represented  by  HICON 
and  LOCON.  When  opposing  side  is  also  played  by  a  part  of  the  TA,  only  the  parts  of  forces  not  controlled  by 
the  TA  is  managed  by  SITFOR. 


Figure  5:  EXCEN  Structure. 

In  NETN,  there  can  be  multiple  EXCON  (see  example  Figure  6a)  or  split  EXCON  (see  example  Figure  6b) 
that  work  collaboratively  or  in  coordination.  In  the  Figure  6b,  the  HICON  is  a  part  of  EXCON  NATO.  For  the 
other  TA,  the  higher  level  command  is  the  TA  NATO. 
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a)  With  a  NATO  HQ  b)  Without  NATO  HQ 


Figure  6:  Examples  for  NETN  Target  Architectures. 


6.3  Using  NETN 

In  order  to  support  training,  an  exercise  architecture  that  meets  the  requirements  of  the  specific  exercise  is 
required.  To  develop  this  exercise  architecture,  the  NETN  reference  documents  provide  some  support.  However, 
to  meet  the  objectives  of  an  exercise,  operational  objectives  need  to  be  transformed  into  technical  federation 
requirements. 

Processes  such  as  FEDEP/DSEEP  can  be  used  to  support  the  development  of  NETN  exercise  architecture  to  fit 
operational  requirements.  The  current  NETN  Reference  Architecture  does  not  include  specific  recommendations 
to  support  the  development  of  NETN  exercise  architecture.  Experimentation  within  MSG-068  had  technical 
objectives  only.  No  experiment  related  to  the  process  transforming  operational  objectives  to  technical  federation 
requirements  was  conducted.  Therefore  MSG-068  recommends  tailoring  DSEEP  to  support  this  transformation 
to  technical  requirements. 


7.0  RECOMMENDATIONS  FOR  THE  ROLES  AND  RESPONSIBILITIES 

MSG-068  NETN  TA  recommendations  for  the  roles  and  responsibilities  are  as  follows: 

•  Maintenance  of  the  NETN  Federation  Architecture  and  FOM  Design  (FAFD)  Reference  Document: 
MSG-068  recommends  that  a  focus  group  working  under  the  NMSG  M&S  Standards  Sub-group  (MS3) 
is  given  the  task  to  maintain  the  core  NETN  Reference  Architecture  documents  including  federation 
agreements  and  the  NETN  FOM  modules.  Configuration  management  related  to  the  individual  FOM 
Modules  and  the  entire  reference  agreements  are  to  be  handled  by  this  group.  The  group  should  report  to 
MS3  and  NMSG  on  the  current  state  of  the  documents  and  make  recommendations  to  task  groups 
concerning  its  use.  The  group  should  also  receive  input  and  feedback  from  users  (including  NMSG  Task 
Groups)  on  their  requirements,  proposed  updates  or  new  additions  related  to  federation  agreements  and 
FOM  modules. 
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•  Operations  and  maintenance  of  an  NETN  persistent  infrastructure  and  services:  MSG-068  recommends 
that  NATO  establish  and  maintain  a  persistent  infrastructure  and  provide  common  services  as  described 
in  Annex  D.  The  establishment  of  this  persistent  infrastructure  should  be  based  on  a  capability  package. 
The  maintenance  team  should  report  to  NMSG  on  the  current  state  of  the  infrastructure  and  make 
recommendations  regarding  updates,  proposed  research  work,  etc.,  based  on  input  and  feedback  from 
users. 

•  Verification,  Validation  and  Accreditation  (VV&A):  MSG-068  recommends  that  NATO  and  Nations 
should  perform  VV&A  on  simulation  assets  according  to  the  Generic  Method  for  Verification  and 
Validation  (GM-VV)  procedures  that  are  currently  being  developed  by  a  joint  team  of  MSG-073  and 
SISO.  Depending  on  future  developments,  a  NATO  body  may  become  available  to  provide  this  service 
for  NATO  assets  as  well  as  for  Nations  if  desired. 

•  Configuration  management  of  the  components  (simulations  and  tools)  within  NETN:  MSG-068 
recommends  that  all  assets  belonging  to  NETN  are  configuration  managed  and  maintained  by  an 
appropriate  body  to  ensure  continued  FAFD  compliancy.  That  role  may  be  a  NATO  body  or  a  Nation 
depending  on  the  asset  that  acts  as  the  custodian  of  the  asset. 

•  Configuration  management  of  NETN  Federations  (NATO  and  Nations):  Specific  Federations  may 
have  extended  Federation  Agreements  and  FOMs  that  are  not  likely  to  become  part  of  the  Reference 
NETN.  MSG-068  recommends  that  all  Federations  based  on  NETN  are  configuration  managed  and 
maintained  by  an  appropriate  body  to  ensure  continued  FAFD  compliancy.  That  role  may  be  a  NATO 
body  or  a  Nation  depending  on  the  asset  that  acts  as  the  custodian  of  the  Federation. 

•  Settings  and  Scenarios  (NATO  and  Nations):  MSG-068  recommends  that  all  Settings  and  Scenarios 
that  are  used  in  (one  or  more)  Federations  based  on  NETN  are  configuration  managed  and  maintained 
by  an  appropriate  body  to  ensure  continued  FAFD  compliancy.  That  role  may  be  a  NATO  body  or  a 
Nation  that  acts  as  the  custodian  of  the  target  Federation. 

•  Development  and  continuous  improvement  in  NETN  (NMSG):  Further  research  with  respect  to 
addressing  some  of  the  gaps  identified  in  the  reference  architecture  should  be  coordinated  by  the  NMSG 
through  the  establishment  of  technical  Task  Groups  (TG).  These  TGs  could  for  example  investigate 
issues  like  C2-Simulation  interoperability,  which  is  a  special  case  of  interoperability  with  live  systems, 
or  topics  like  multi-level  security. 

•  Procedures  for  certification  of  federates  and  federations:  MSG-068  recommends  that  NATO  and 
Nations  should  perform  HLA  certification  on  simulation  assets  that  are  intended  for  NETN  according 
to  the  procedures  defined  by  the  NMSG  Certification  Advisory  Group  (CeAG).  Note  that  CeAG  reports 
to  NMSG  MS3.  Several  commercial  organisations  and  some  government  offices  provide  Certification 
services  according  to  the  CeAG  procedures.  MSG-068  also  recommends  that  CeAG  should  further 
develop  its  procedures  and  tool  support  to  provide  a  deeper,  more  comprehensive  and  thus  more 
valuable  certification  that  extends  beyond  basic  HLA  compliancy. 

•  Integration  and  testing  of  federations:  Certification  of  individual  assets  is  a  first  step  towards  improved 
integration  and  testing  of  federations.  MSG-068  recommends  that  NATO  and  Nations  should  follow 
current  best-practices  according  to  FEDEP/DSEEP.  There  is  however  certainly  work  to  be  done  by 
NMSG  to  develop  more  guidance  in  this  area. 


8.0  EXPERIMENTATION  AND  DEMONSTRATION 

MSG-068  recommendations  were  tested  in  a  standalone  distributed  experimentation  event  between  October 
25  and  November  5,  2010.  Ten  Nations  (Bulgaria,  France,  Germany,  Hungary,  Netherlands,  Spain,  Sweden, 
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Turkey,  UK,  US)  and  5  NATO  HQs/organizations  (HQ-SACT,  JWC,  JFTC,  NC3A,  M&S  CoE)  joined  the 
experiment  from  one  of  5  different  locations  (Bydgoszcz,  Paris,  Ottobrunn,  Porton  Down,  The  Hague).  JTLS, 
JCATS  and  PLEXCOMM  from  the  U.S.,  TYR  from  Sweden,  VBS2  from  Australia  (three  separate  copies  of 
VBS2),  MARCUS  from  Hungary,  ORQUE  and  WAGRAM  from  France,  VR-Forces  from  Spain,  FACSIM 
from  the  Netherlands,  KORA  from  Germany  and  ITC/FLAMES  from  NC3A  were  federated  by  using  MSG- 
068  Reference  Federation  Architecture  during  the  experiment. 

The  experiments  are  grouped  into  three  categories  as  technical  experiments  for  the  infrastructure,  technical 
experiments  for  the  reference  federation  architecture  and  operational  use  case  experiments  for  the  NETN 
federations.  The  following  two  incidents  were  designed  for  the  technical  experiments  for  the  reference  federation 
architecture: 

•  Incident  1  (Campaign  1)  consists  of  a  sea  lift,  a  UAV  recce,  a  cruise  missile  strike,  a  ground  strike  with 
close  air  support  and  indirect  fires,  a  blocking  by  marines  and  a  MEDEVAC. 

•  Incident  2  (Campaign  2)  consists  of  a  UAV  recce,  an  air  strike,  two  ground  strikes,  a  blocking  by 
marines,  a  hostage  situation,  repair  of  equipments  and  ammunition  resupply. 


Figure  7:  Experiment  Cells. 


In  every  part  of  these  incidents  multiple  federates  (i.e.,  simulation  systems)  were  involved  in  and  interacted 
with  each  other  through  a  federation  built  on  NETN  Reference  Federation  Architecture.  Both  Campaign  1  and 
2  were  run  first  in  the  Internet.  Then  Campaign  1  was  run  in  the  CFBLNet  when  the  bearer  was  NGCS. 
Finally  Campaign  2  was  run  in  the  CFBLNet  when  the  bearer  was  the  Internet. 
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Figure  8:  Experimentation  Center. 

Also  the  following  four  incidents  were  executed  to  test  the  operational  use  cases:  a  MEDEVAC  incident, 
a  VBS2-NATO  demonstration  for  advanced  distributed  C-IED  training,  a  Forward  Air  Controller  (FAC)  training 
by  using  NLVC  and  a  shared  scenarios  demonstration.  FAC  training  by  NFVC  consisted  of  a  Forward  Air 
Controller  in  Bydgoszcz,  an  F-16  pilot  in  The  Hague,  a  UAV  in  Porton  Down  and  a  second  UAV  in  Bydgoszcz. 
The  vignette  was  repeated  three  times  for  a  different  FAC  each  time.  The  FACs  were  operational  people  from 
Poland  (2x)  and  Germany,  the  FAC  instructor  came  from  the  Dutch  Air  Ground  Operations  School. 

First  impression  report  of  MSG-068  Final  Experiment  is  at  Ref.  [12].  NC3A  also  conducted  a  survey  during  the 
experiment.  The  results  of  this  survey  are  at  Ref.  [13].  Based  on  the  analysis  of  comments  provided  by 
respondents  of  the  NETN  Survey,  the  following  additional  recommendations  can  be  made: 

•  Enhance  the  technical  standards  to  include  areas  such  as: 

•  Distributed  exercise  preparation  and  management; 

•  Integration  of  NATO  and  national  C2  systems  with  the  training  environment; 

•  Allocation  of  the  execution  of  tasks  within  the  federation; 

•  Management  of  perception; 

•  Management  of  multi-granularity  (multi-resolution); 

•  Shared  scenarios;  and 

•  Federation  management. 

Benefit:  Wider  application  potential  of  the  recommendations  to  the  exercise  domain. 

•  Expand  procedures  and  tools  to  ensure  compliance  of  federates  and  processes  with  the  complete  set  of 
technical  standards.  The  responsibility  and  roles  in  compliance  testing  should  be  assigned  explicitly. 

Benefit:  If  compliance  is  ensured,  composing  and  configuring  a  federation  for  a  distributed  exercise 
will  require  less  time  and  the  risk  during  execution  will  be  reduced  significantly. 

•  Sustain  the  use  of  CFBFNet,  but  validate  the  assumption  about  CFBFNet’s  ability  to  provide  secure 
services. 

Benefit:  Efficient  environment  for  federation  composition  and  expansion. 
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During  the  I/ITSEC  2010  conference  MSG-068  provided  also  a  live  demonstration  of  the  core  NETN 
technologies.  Systems  from  France,  Germany,  Spain,  Sweden,  UK,  USA,  NC3A,  Joint  Warfare  Center  (JWC) 
and  Joint  Force  Training  Center  (JFTC)  were  connected  in  a  distributed  federated  simulation  running  both  locally 
in  the  booth  and  connected  to  remote  sites  in  Europe.  The  following  simulation  systems  participated  in  the 
demonstration: 

•  ORQUE,  WAGRAM  (France); 

•  JTLS  (JWC); 

•  VBS2  (UK); 

•  KORA  (Germany); 

•  ITC  FLAMES/ICC  (NC3A,  JFTC); 

•  TYR,  pRTI  1516  Evolved  (Sweden); 

•  PLEXComm  (USA); 

•  JCATS  (USA);  and 

•  VR  Forces  (Spain). 


9.0  CONCLUSION  AND  WAY  AHEAD 

NATO  Modelling  and  Simulation  Group  of  NATO  Research  and  Technology  Agency  started  MSG-068 
NETN  upon  request  by  HQ-SACT  in  2007.  Thirteen  Nations  and  five  NATO  organizations  contributed  to 
MSG-068  to  develop  and  demonstrate  standards  and  recommendations  for  a  persistent  education  and  training 
network  that  comprises  of  tools  for  advanced  distributed  learning,  resource  sharing  and  distributed  simulations. 

MSG-068  conducted  a  standalone  experiment  in  order  to  validate  the  MSG-068  recommendations  for: 

•  A  secure,  persistent,  on-demand  training  capability  that  integrates  national  centres  and  NATO; 

•  Capability  and  readiness  of  NATO,  Nations  and  national  simulation  centres  to  link  into  NETN; 

•  Distributed  simulation  integrating  NATO  and  national  M&S  capabilities; 

•  Multi-granularity; 

•  Technical  standards; 

•  Distributed  training  involving  national  and  NATO  C2  and  simulation  systems;  and 

•  Shared  scenarios. 

The  experiment  achieved  the  objectives  in  validating  the  recommendations  and  clarifying  the  requirements  for 
further  improvements.  The  requirements  for  future  work  can  be  categorized  into  three  classes: 

•  The  requirements  related  to  infrastructure  can  be  listed  as  follows: 

•  The  procedures  for  joining  CFBLNet  or  extending  an  existing  PoP  should  be  simplified  and 
clarified. 

•  When  CFBLNet  is  used,  it  introduces  another  technical  management  level  on  top  of  the  technical 
administration  of  the  bearer  networks.  The  user  needs  to  manage  these  two  layers  separately  for 
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multiple  sites,  which  is  not  always  practical.  A  scheme  to  unify  the  management  of  infrastructure 
(i.e.,  to  provide  single  point  of  contact  for  the  infrastructure)  needs  to  be  developed. 

•  Better,  more  reliable,  robust  and  practical  multi-level  security  protocols  and  procedures  are  yet  to 
be  investigated  and  developed  for  more  flexible  infrastructure. 

•  CFBLNet  may  be  a  semi  persistent  solution  used  for  specific  events  when  needed  for  some 
Nations.  The  selection  between  persistent  and  semi  persistent  solution  depends  on  the  frequency  of 
CFBLNet  usage.  The  implications  of  this  approach  needs  to  be  further  studied  with  more  detailed 
technical  and  procedural  perspective  by  a  focus  group. 

•  Further  clarification  and  experimentation  with  respect  to  integration  of  other  simulation 
architectures  into  NETN  (e.g.,  gateways  integrating  live  players)  is  required. 

•  The  requirements  related  to  FAFD  can  be  further  grouped  as  follows: 

•  The  FAFD  issues  identified  but  not  addressed: 

•  Transfer  of  Ownership  (Modeling  Responsibility); 

•  Further  modularization  of  FOM  Modules,  e.g.,  RPR-FOM; 

•  Extension  of  NETN  FOM  modules  to  support  the  other  data  links;  and 

•  Agreements  on  scalability  and  performance. 

•  The  issues  requiring  additional  development,  test  and  experimentation: 

•  Protocol  for  Aggregation/De-aggregation; 

•  Transfer  of  Control  in  Aggregation/De-aggregation; 

•  Combat  Adjudication; 

•  Federation  Execution  Control;  and 

•  Exceptions  and  Variations  of  Logistics  Patterns. 

•  The  requirements  related  to  shared  scenarios  has  been  grouped  as  follows: 

•  HQ-SACT  has  completed  a  project  on  shared  scenarios,  and  the  results  from  this  project  are 
included  as  a  reference  [11]  in  this  report.  The  project  determined  some  shortcomings  in 
shared  scenarios  concept  in  particular  on  how  to  apply  the  available  material  to  user  needs. 
MSG-068  recommends  that  ACT  develops  and  organizes  a  training  program  for  this  purpose. 

•  Providing  common  scenario  initialization  information  to  all  federates  enables  data  correlation 
among  federates  and  reduces,  if  not  precludes,  instances  of  data  mapping  errors.  MSG-068 
recommends  further  study  of  common  scenario  initialization  methodologies  and  tools. 

Apart  from  the  infrastructure,  FAFD  and  shared  scenarios,  MSG-068  also  developed  recommendations  with 
respect  to  roles  and  responsibilities,  and  additional  work.  This  set  of  recommendations  need  to  be  implemented 
by  NATO  and  the  Nations  to  achieve  the  NETN  vision.  For  NATO,  MSG-068  recommends  either  a  new 
capability  package  or  an  amendment  to  an  existing  capability  package  to  act  on  the  recommendations. 


10.0  REFERENCES 

[1]  ACT  Directive  for  Operating  JWC,  JFTC  and  JALLC  (80-3),  Version:  Latest,  March  2004. 

[2]  ACT  Directive  for  the  Implementation  of  JWC,  JFTC  and  JALLC  Plan  of  Action  and  Milestones 
(80-6,  Version:  Latest,  December  2004. 


RTO-TR-MSG-068 


21 


NATO  EDUCATION  AND  TRAINING  NETWORK 


ORGANIZATION 


[3]  Provide  Joint  Training,  Experimentation  and  Interoperability  Development  Capabilities  (CP  9B0401), 
Version:  Latest,  June  2004. 

[4]  JWC  and  JFTC  Training  and  Experimentation  Facility  AIS  Concept  User  Requirements  Analysis,  Version: 
1.1,  December  2005. 

[5]  BI-SC  75-3  Exercise  Directive,  Version:  Latest,  April  2007. 

[6]  MSG-068  NETN  TAP,  Version:  Latest,  April  2007. 

[7]  MSG-068  NETN  TOR,  Version:  Latest,  April  2007. 

[8]  MSG-052  Final  Technical  Report,  To  be  Published. 

[9]  STANAG  4603. 

[10]  IEEE  Standard  1516-2010,  2010. 

[11]  HQ-SACT  Shared  Scenarios  Project  Report,  Version:  Latest,  September  2010. 

[12]  MSG-068  Experiment  First  Impression  Report,  Version:  Latest,  November  2010. 

[13]  MSG-068  Experiment  Survey  Analysis,  Version:  2.1,  November  2010. 

[14]  Draft  TAP  and  TOR  for  the  Follow  on  Task  Group,  Version:  4.0,  March  2011. 

[15]  Bowers,  F.  and  Gregg,  B.,  “Use  of  Unique  Identifiers  to  Enable  Interoperability  Among  LVC  Components”, 
Proceeding  of  the  NATO  Modeling  and  Simulation  Group  076  Symposium,  Utrecht,  Netherlands, 
September  2010. 

[16]  RTO-TR-SAS-034  AC/323(SAS-034)TP/50  -  Mission  Training  via  Distributed  Simulation  and  First 
WAVE:  Final  Report. 

[17]  Gehr,  S.E.,  Schurig,  M.,  Jacobs,  L.,  van  der  Pal,  J.,  Bennett,  Jr.,  W.  and  Schreiber,  B.,  “Assessing  the 
Training  Potential  of  MTDS  in  Exercise  First  Wave”,  Paper  MSG-035-1 1 . 

[18]  [HUI2009]  Huiskamp,  W.,  Wymenga,  R.,  Krijnen,  R.  and  Harmsen,  E.,  Network  Infrastructure  Design 
Document  for  NATO  Education  and  Training  Network  (NETN),  June  2009. 

[19]  [AMSP01],  Allied  Modelling  &  Simulation  (M&S)  Publication  01  (AMSP-01)  NATO  M&S  Standards 
Profile  -  Prepared  by  the  NATO  M&S  Group  (NMSG),  M&S  Standards  Subgroup  (MS3), 
(https://transnet.act.nato.  int/WISE/COE/Individual/MS/ReferenceD/NATOMSStan/file/_WFS/AMSP- 

0 1  %28A%29%20NATO%20M%26S%20Standards%20profile.pdf),  2009. 

[20]  NATO  Simulation  Resource  Library  (NSRL)  Ref  NSRL  on  NMSG  website. 


22 


RTO-TR-MSG-068 


Annex  A  -  TECHNICAL  ACTIVITY  PROGRAM 


Activity 

TG 

Activity  Title 

Distributed  Training  and  Exercises  (DTE) 
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Interoperability,  Simulation,  Planning,  Analysis, 
Operational  support,  Combined  Joint  Operations 

I.  BACKGROUND  AND  JUSTIFICATION 

In  2007,  HQ-SACT  initiated  a  NATO  Education  and  Training  Network  (NETN)  project,  which  later  became 
Program  Snow  Leopard,  to  establish  a  persistent,  joint  NETN  capability  at  the  strategic,  operational, 
and  tactical  levels  by  leveraging  existing  national  capabilities.  In  2010  Snow  Leopard  was  renamed 
Distributed  Training  and  Exercises  (DTE)  to  more  clearly  identify  the  program’s  purpose. 

The  DTE  vision  provides  dynamic,  capability-based  training  for  NRF,  CJTF,  and  NATO  and  Partner 
Nation  forces  in  support  of  NATO  security  objectives  across  a  full  range  of  integrated  operations.  DTE 
will  comprise  virtual  and  constructive  (VC)  environments,  and  leverage  distributed  training  and  shared 
resources  to  ensure  that  NATO  and  Partner  forces  receive  state-of-the-art  training  relevant  to  current 
operational  requirements. 

NATO  M&S  Group  068  developed  initial  technical  solutions  to  enable  DTE.  A  final  Stand  Alone 
Experiment  (SAE)  showed  the  technical  feasibility  of  a  network  of  distributed  simulations.  A  demonstration 
during  I/ITSEC  2010  elicited  strong  interest  from  numerous  nations  for  a  reference  architecture  and 
community  standards. 

However,  the  initial  technical  capability  is  insufficient  to  support  the  full  DTE  vision.  NMSG-068 
recommended  additional  technical  development.  NMSG-068  noted  the  lack  of  an  established  long  term 
process  for  the  maintenance  of  the  initial  reference  architecture  and  standards,  nor  provisions  for 
improvement.  Finally,  NMSG-068  was  unable  to  more  closely  link  or  assess  its  capabilities  against  the 
operational  support  requirements. 

II.  OBJECTIVE(S) 

The  objective  of  the  Task  Group  (TG)  is  to  establish  a  long  term  process  for  the  maintenance  of  the  initial 
reference  architecture  and  standards.  The  TG  will  also  recommend  a  process  consistent  with  the  IEEE 
1516.3  Federation  Development  and  Execution  Process  (FEDEP)  whereby  Nations  and  Partners  may 
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recommend  and  realize  improvement  in  the  reference  architecture  and  standards.  Finally,  the  Task  Group 
will  act  on  NMSG-068  recommendations  for  technical  development  to  evolve  the  initial  reference  architecture 
and  standards  to  a  degree  sufficient  to  support  NRF,  CJTF,  and  NATO  and  Partner  Nation  exercises. 

III.  TOPICS  TO  BE  COVERED 

1)  Establish  a  long  term  maintenance  process  for  DTE  products  (FOM,  FAFD,  certification, 
standardisation). 

2)  Establish  a  process  for  DTE  product  improvement  consistent  with  the  IEEE  1516.3  FEDEP. 

3)  Establish  a  process  for  scenario  generation  and  data  correlation  sufficient  to  support  NRF,  CJTF,  and 
NATO  and  Partner  Nation  exercises. 

4)  Enable  transfer  of  modelling  responsibility/ownership  transfer  in  DTE  federations  to  support  NRF, 
CJTF,  and  NATO  and  Partner  Nation  exercises. 

5)  Recommend  means  to  improve  scalability  in  DTE  federations  sufficient  to  support  NRF,  CJTF,  and 
NATO  and  Partner  Nation  exercises. 

6)  Provide  guidance  for  the  organization  and  management  of  distributed  exercises. 

7)  Support  distributed  exercises  proposed  by  the  nations. 

IV.  DELIVERABLES  AND/OR  END  PRODUCT 

1)  Process  for  DTE  maintenance  and  product  improvement  consistent  with  the  IEEE  1516.3  FEDEP. 

2)  Improved  DTE  products  (data  mapping,  transfer  ownership,  scalability,  etc.). 

3)  Guidance  for  the  organization  and  management  of  distributed  exercises  using  DTE. 

4)  Recommendations  for  the  DTE  product  updates. 

5)  Lessons  learned  in  DTE  product  support  of  a  NATO  and/or  Partner  Nation  exercise(s). 

6)  Testing  Documentation,  results,  and  recommendations. 

7)  Final  technical  report. 

V.  TECHNICAL  TEAM  LEADER  AND  LEAD  NATION 

ACT 

LTC  Laurent  Tard,  France 
Ms.  Amy  Grom,  USA 

Sweden  (Ulf  Jinestrand)  will  be  contacted  by  France  (TBC) 

VI.  NATIONS  AND  ORGANIZATIONS  WILLING  TO  PARTICIPATE 

Canada  (?),  France,  Germany  (?),  The  Netherlands  (?),  Spain  (?),  Sweden  (?),  United  Kingdom  (?),  United 
States  of  America,  ACT,  Joint  Warfare  Centre  (JWC)  (?),  NC3A  (?),  NATO  M&S  COE  (?),  Others  ??? 
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VII.  NATIONAL  AND/OR  NATO  RESOURCES  NEEDED 

1)  National  and  NATO  technical  staff. 

2)  Travel  costs  for  nations  and  NATO  organizations. 

3)  Unclassified  information  about  national  training  lessons  learned. 

4)  Tools  for  distributed  exercises. 

5)  Network  assets. 

6)  Unclassified  national  and  NATO  ORB  AT  data. 

7)  HQ-SACT  funding  for  the  NC3 A  participation. 

8)  Support  from  national  and  NATO  centres  of  simulation  and  training. 

9)  Invitations  to  support  distributed  exercises. 


VIII.  RTA  RESOURCES  NEEDED 

MSCO  support. 

Publication  of  reports. 
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Annex  B  -  NETN  SURVEY:  BACKGROUND 
AND  INTRODUCTION 


NC3A  conducted  an  ACT-sponsored  survey  as  part  of  the  NETN  Experiment  in  November  2010.  The  aim 
of  the  survey  was  to  provide  an  assessment  of  the  effort  needed  to  establish  and  operate  the  NETN 
capability.  Although  the  number  of  responses  to  the  survey  was  limited,  they  were  sufficient  to  develop 
initial  recommendations.  However,  the  number  of  responses  was  too  limited  to  be  able  to  present  a  full 
picture. 


B.l  OBSERVATIONS 

1)  Due  to  the  limited  number  of  valid  responses,  we  couldn’t  establish  a  baseline  on  the  overall  effort 
needed  to  prepare  and  execute  a  distributed  training  event  based  on  NETN.  However  it  seems  that  the 
effort  is  moderate  and  comparable  to  other  federations  that  are  applied  in  most  nations  and  NATO 
organizations. 

2)  Due  to  the  limited  extent  of  the  vignettes  and  technical  focus  of  the  experiment,  the  teams  at  all  sites 
were  small.  Therefore  there  was  no  need  for  a  formalized  approach  to  distributed  coordination  of  the 
experiment  preparation  and  execution.  A  simple  combination  of  tools  like  VoIP  and  phone  was  used. 

3)  Although  focused  technical  compliance  testing  was  clearly  defined  and  well  supported  by  tools,  it  was 
not  sufficient  to  prevent  undesirable  side  effects  during  execution  of  the  various  vignettes. 

B.2  CONCLUSIONS 

The  table  below  summarizes  the  Analysis  Objectives  and  the  answers  that  were  provided  by  Survey 

respondents. 


Analysis  objectives 


A02.1:  To  which  extent  is  it  feasible  to  establish  and  operate  a  secure,  permanently  available 
(it  is  there  and  tested  but  not  necessarily  running)  training  infrastructure  between  NATO  and 
national  training  centres  that  can  be  used  on  demand  using  CFBLNet? 

Answer:  It  is  feasible  to  establish  and  operate  a  permanently  available  training  infrastructure 
between  NATO  and  national  training  centres  using  CFBLNet.  CFBLNet  services  are  available 
on-demand,  require  low  effort  to  establish  and  operate,  and  provide  good  quality  of  service. 
The  security  aspect  has  not  been  experimented  with,  but  CFBLNet  has  a  proven  track  record  in 
providing  secure  services. 

A02.2:  To  which  extent  were  alternatives  to  CFBLNet  considered? 


Answer:  Internet  was  considered  and  used  as  an  alternative  to  CFBLNet.  However,  making  the 
Internet  connection  secure  would  be  much  more  difficult  than  in  case  of  CFBLNet. 


A02.3:  To  which  extent  could  alternatives  to  CFBLNet  be  considered? 


Answer:  Not  available. 
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ANNEX  B  -  NETN  SURVEY:  BACKGROUND  AND  INTRODUCTION 


Analysis  objectives 


A03.1:  To  which  extent  is  it  feasible  to  establish  and  operate  distributed  simulation  integrating 
NATO  and  national  simulations  and  training  management  tools? 

Answer:  An  analysis  of  the  answers  to  the  various  questions  that  were  developed  to  assess  the 
feasibility  to  establish  distributed  simulation  shows  that  a  concerted  sizeable  effort  by  specialised 
personnel  is  required  for  an  extended  period.  Indeed  the  contribution  to  the  FOM  development 
required  an  average  of  72-man-days  by  a  team  of  3  to  4  specialist  personnel,  a  limited 
investment  (avg  20  KEuro)  in  tools  and  travel.  Compliance  testing  required  an  additional 
average  effort  of  60  man-days  by  a  team  of  2  to  3  specialist  personnel  and  avg  25  KEuro 
investment.  Answers  pertaining  to  the  actual  operational  usage  and  the  associated  data 
preparation  and  federation  management  effort  were  not  received.  Therefore  we  cannot  make 
any  conclusions  about  the  operation  of  distributed  simulation  in  an  actual  operational  training 
context. 


A03.2:  To  which  extent  were  other  options  to  achieve  similar  objectives  considered? 

Answer:  Seven  responses  were  received  that  indicate  that  alternatives  were  studied. 
The  assessment  is  that  an  average  of  100  to  120  man-days  would  be  required  by  a  team  of  2  to  4 
specialist  personnel  to  extend  a  single  simulation  to  provide  the  functionality  that  was  provided 
by  the  NETN  federation.  An  average  investment  of  50  to  60  KEuro  would  be  required  to 
complement  the  development  effort. 

A04.1:  To  which  extent  are  the  technical  standards  that  have  been  applied  in  the  development 
of  the  NETN  federation  sufficient  to  support  the  establishment  and  operation  of  a  flexible 
distributed  simulation  environment  integrating  NATO  and  national  simulation  and  training 
management  tools? 

Answer:  The  technical  standards  are  sufficient  to  a  limited  extent.  They  are  clear  and  they 
enable  simulations  to  talk  with  each  other,  but  do  not  cover  other  important  areas  like 
management  of  the  network  and  of  the  federation,  perception,  and  interface  to  C2  systems. 
Application  of  the  currently  recommended  technical  standards  requires  considerable  effort, 
which  is  however  not  different  from  effort  needed  to  apply  previous  technical  standards. 

A06.1:  To  which  extent  can  the  shared  scenario  library  be  filled  and  searched  to  enable  exercise 
designers  to  share  and  retrieve  useful  scenario  descriptions? 

Answer:  Submission  is  not  entirely  clear  and  requires  more  explanation  of  the  terms  that  are 
being  used.  The  submission  tool  combines  easy  and  more  complicated  parts.  Its  user  friendliness 
can  do  to  be  improved.  Searching  the  library  is  a  simple  mechanism.  As  above,  conclusions  need 
to  be  qualified  due  to  the  very  limited  response. 

A06.2:  With  respect  to  the  scenario  that  is  being  used  in  the  NETN  experiment,  to  which  extent 
can  an  existing  scenario  be  shared  across  a  federation? 

Answer:  Responders  indicated  that  the  average  level  of  effort  that  was  required  consisted  of 
approximately  25  man-days  for  each  simulation  to  set-up  data  in  accordance  with  the  existing 
scenario  by  a  specialist  team  of  1  to  2  persons  and  an  investment  averaging  25  KEuro  for  tools 
and  travel.  Data  expansion  was  required  in  most  cases  to  a  limited  extent.  Limited  effort  was 
devoted  for  data  and  entity  behaviour. 
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ANNEX  B  -  NETN  SURVEY:  BACKGROUND  AND  INTRODUCTION 


Analysis  objectives 


A07.1:  To  which  extent  can  the  NETN  reference  architecture  support  distributed  simulation 
integrating  NATO  and  national  simulations  and  training  management  tools  at  multiple  levels  of 
granularity? 

Answer:  The  selection  of  granularity  is  considered  difficult  when  there  are  options.  Indeed  in  an 
entity-level  simulation  the  level  of  granularity  is  fixed.  The  experiment  scenario  did  not  provide 
sufficient  opportunity  to  test  this  aspect. 


B.3  ADDITIONAL  RECOMMENDATIONS 

Based  on  the  analysis  of  comments  provided  by  respondents  of  the  NETN  Survey,  the  following 
additional  recommendations  can  be  made: 

1)  Enhance  the  technical  standards  to  include  areas  such  as: 

•  Distributed  exercise  preparation  and  management; 

•  Integration  of  NATO  and  national  C2  systems  with  the  training  environment; 

•  Allocation  of  the  execution  of  tasks  within  the  federation; 

•  Management  of  perception; 

•  Management  of  multi-granularity  (multi-resolution); 

•  Shared  scenarios;  and 

•  Federation  management. 

Benefit:  Wider  application  potential  of  the  recommendations  to  the  exercise  domain. 

2)  Expand  procedures  and  tools  to  ensure  compliance  of  federates  and  processes  with  the  complete  set 
of  technical  standards.  The  responsibility  an  d  roles  in  compliance  testing  should  be  assigned 
explicitly. 

Benefit:  If  compliance  is  ensured,  composing  and  configuring  a  federation  for  a  distributed  exercise 
will  require  less  time  and  the  risk  during  execution  will  be  reduced  significantly. 

3)  Sustain  the  use  of  CFBLNet,  but  validate  the  assumption  about  CFBLNet’s  ability  to  provide  secure 
services. 

Benefit:  Efficient  environment  for  federation  composition  and  expansion. 
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1  Introduction 


1.1  Purpose 

The  purpose  of  this  document  is  to  provide  a  common  reference  federation  agreements  document  (FAD)  for  all 
federations  in  the  NATO  Education  and  Training  Network  (NETN).  Agreements  that  are  common  to  all  NETN 
based  federations  are  specified  in  this  document.  Templates  for  documenting  required  federation  specific 
agreements  are  also  provided.  Principles  and  format  for  information  exchange  between  federates  in  a  NETN 
based  federation  is  defined  in  the  FAD.  As  part  of  the  federation  agreements  a  module  based  HLA  reference 
Federation  Object  Model  (FOM)  is  provided. 

1.2  Use 

This  document  is  intended  to  be  used  as  a  template  and/or  reference  when  developing  federation  specific 
agreements.  In  any  specific  federation  more  detailed  and  other  types  of  agreements  are  almost  always 
required.  This  reference  agreement  document  is  not  intended  to  replace  the  need  for  developing  federation 
specific  agreements. 

1.3  Background 

This  version  of  the  NETN  Reference  FAD  was  developed  by  NATO  Modeling  and  Simulation  Group  (NMSG)  Task 
Group  MSG-068  NETN.  This  task  group  was  initiated  to  support  the  ACT  Snow  Leopard  Program  with  M&S 
recommendations  for  establishing  a  NATO  wide  network  for  education  and  training  (NETN),  a.k.a.  Snow 
Leopard. 

A  technical  subgroup  of  MSG-068,  Federation  Agreements  and  FOM  Design  (FAFD)  subgroup  was  created  with 
representatives  from  the  participating  NATO  and  partner  nations.  This  group  represented  a  broad  community 
of  practice  with  respect  to  federation  architecture  and  design.  Major  systems,  federations  and  training 
networks  were  represented  in  the  FAFD  group.  The  input  provided  and  the  harmonization  of  federation 
architecture  and  design  agreements  forms  the  basis  of  this  document. 

Key  input  to  the  development  of  this  FAD  includes: 

•  ALLIANCE  FOM 

•  CASIOPEA  FOM 

•  JLVCFOM 

•  JMRM FOM 

•  KOSI  FOM 

•  P2SN  FOM 

•  RPR-FOM  v2.0 
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1.5  References 

While  this  document  is  intended  to  be  sufficiently  complete  to  be  read  stand  alone,  time  does  not  allow  for  all 
concepts  to  be  explained  fully.  Please  refer  to  the  documents  referenced  below  for  more  details.  This 
document  borrows  especially  heavily  from  the  RPR-FOM  v2.0  D17  documentation.  In  the  case  of  differences 
between  this  document  and  the  references,  this  document  is  primary. 

The  list  of  references  indicates  relevant  standards  that  should  be  considered  during  the  development  of 
distributed  simulation  systems.  Some  of  these  are  not  referenced  in  the  main  body  of  the  document. 

•  Distributed  Interactive  Simulation  (DIS) 

IEEE  1278.1-1995  Application  Protocols 

IEEE  1278. la-1998  Supplement  to  Application  Protocols  -  Enumeration  and  Bit-encoded  Values 
IEEE  1278.2  -  Communication  Services  and  Profiles 

IEEE  1278.3  -  Exercise  Management  &  Feedback  (EMF)  -  Recommended  Practice 
SISO-REF-010-2006  DIS  Enumerations 

•  High  Level  Architecture  (HLA) 

IEEE  1516-2000  Framework  and  Rules 

IEEE  1516.1-2000  Federate  Interface  Specification 

IEEE  1516.2-2000  Object  Model  Template  (OMT)  Specification 

IEEE  1516.3-2003  Federation  Development  and  Execution  Process  (FEDEP) 

IEEE  1516.4-2007  Verification,  Validation,  and  Accreditation  of  a  Federation 

IEEE  1516-2010  HLA  "Evolved"  Framework  and  Rules 

IEEE  1516.1-2010  HLA  "Evolved"  Federate  Interface  Specification 

IEEE  1516.2-2010  HLA  "Evolved"  Object  Model  Template  (OMT)  Specification 

•  Real-time  Platform  Reference  Federation  Object  Model  (RPR-FOM) 

SISO-STD-OOl-1999:  Guidance,  Rationale,  &  Interoperability  Modalities  for  the  RPR  FOM  (GRIM  1.0) 
SISO-STD-001. 1-1999:  Real-time  Platform  Reference  Federation  Object  Model  (RPR  FOM  1.0) 

RPR  FOM  v2.0  D17  FOM 
RPR  FOM  v2.0  D17GRIM 

•  SISO-STD-004-2004:  Dynamic  Link  Compatible  HLA  API  Standard  for  the  HLA  Interface 

•  Specification  Version  1.3 

•  SISO-STD-004. 1-2004:  Dynamic  Link  Compatible  HLA  API  Standard  for  the  HLA  Interface  Specification 
(IEEE  1516.1  Version) 

•  NATO  STANAG  4603 

•  IEEE  P1703  Distributed  Simulation  Engineering  and  Execution  Process  (DSEEP) 

•  SISO-STD-002-2006:  Standard  for:  Linkl6  Simulations 

•  SISO-STD-003-2006;  Base  Object  Model  (BOM)  Template  Specification  (approved  8  May  06) 

•  SISO-STD-003. 1-2006;  Guide  for  BOM  Use  and  Implementation  (approved  8  May  06) 

•  SISO-STD-007-2008:  Military  Scenario  Definition  Language  (MSDL) 


2  Design  Agreements 

Agreements  related  to  the  overall  design  of  the  federation  shall  be  documented  in  the  federation  agreements. 
This  includes  information  about  the  connected  systems,  their  role  and  their  purpose  in  the  federation.  A 
system  can  consist  of  several  hardware  and  software  components  and  each  system  can  run  in  multiple 
instances. 


System  Name 

Hardware 

Software 

Description 

Purpose 

POC 

<Name  and 

version> 

<List  of 

HW> 

<List  of  SW> 

<System 

Description> 

<Purpose/Role  in  the 
Federation> 

<POC 

information> 

... 

For  clarity,  the  federation  agreements  should  also  contain  figures  describing  the  main  systems  of  the 
federation. 

Example: 
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3  Infrastructure  Agreements 


3.1  CFBL-Net 

The  Combined  Federated  Battle-Lab  Network  (CFBL-net)  is  a  core  network  component  of  the  NETN  Federation 
Architecture.  This  network  provides  a  managed  secure  IP  network  used  to  connect  accredited  sites  and 
national  networks.  However,  the  NETN  Reference  Federation  Agreements  document  can  also  be  applied  to 
federations  running  on-top  of  other  IP  based  networks  including  the  Internet. 

3.2  Booster  Network 

The  NETN  Federation  Architecture  recommends  using  a  simulation  overlay  network  ("Booster  Network")  on- 
top  of  existing  IP  network  to  create  a  persistent  capability  to  access  and  connect  to  the  various  simulation 
resources  without  the  need  for  a  specific  technical  setup  or  configuration.  The  Booster  Network  hides  the 
complexity  of  the  physical  networking  infrastructure,  simplifies  the  federation  setup  and  optimizes  simulation 
performance  over  WAN  by  providing  an  HLA-aware  software  router.  The  NETN  Reference  Federation 
Agreements  document  does  not  explicitly  require  this  technology  and  can  also  be  applied  to  federations 
running  without  Booster  Network. 

Agreements  on  how  the  booster  network  is  configured  shall  be  documented  in  a  table  describing  each  node. 


Name 

Address 

Location 

<Logical  Name  of  Boosters 

<Public  IP> 

Geographical  Location  or  address> 

... 

3.3  Sites 

In  NETN  federations  the  unique  identification  of  sites  is  a  vital  part  of  agreements  related  to  the  representation 
of  simulated  entities.  A  list  of  site  IDs  is  therefore  required  to  be  completed  as  part  of  a  federation  specific  FAD. 
The  unique  site  identifier  is  also  used  as  part  of  unique  identifiers  of  simulated  entities  in  the  federation  as 
defined  in  the  RPR-FOM  datatype  "Entityldentifier". 

3.4  IP  Addresses 

All  systems  connected  to  the  network  infrastructure  shall  be  assigned  IP  addresses.  The  method  for  assigning 
these  addresses  can  vary  depending  on  the  underlying  network  policies  and  procedures.  A  complete  list  of  all 
IP  addresses  of  all  hosts  involved  in  a  specific  experiment  and  their  purpose  must  be  listed  in  the  Federation 
Specific  FAD. 

3,4,1  IP  addresses  and  Site  Identifiers  in  CFBL-Net 

The  CFBL-Net  formula  for  assigning  IPs  is  straightforward  and  typically  in  the  following  format.  From  a  CFBL-Net 
view  each  nation  is  given  a  16  address  block  and  National  (NNN)  id. 

Format:  III.NNN.SSS.### 

•  III  is  initiative  id 

•  NNN  is  the  national  id 

•  SSS  is  the  CFBL-Net  site  identifier 

Each  site  shall  correspond  with  a  fixed  IP  range.  The  hosts  on  each  site  needed  for  the  experiment  shall  get  an 
IP  address  from  this  range.  By  using  VPN  technology  all  hosts  in  the  network  can  be  accessed  by  their  IP 
address. 


3,4,2  Site  Identifier  Reference 

Sites  connecting  through  CFBL-net  are  given  a  unique  site  identifier  corresponding  to  the  CFBL-Net  IP  setup. 
For  all  other  federation  agreements  all  sites  identifiers  should  use  the  reference  table  below  as  the  basis  for 
assigning  site  identifiers.  Only  series  of  Site  ID  for  nations  participating  in  the  development  of  this  Reference 
Document  have  been  included  in  this  version  of  the  reference  agreements. 

Site  IDs  should  be  in  the  range  1  -  65534 


Site  Name 

Site  ID 

Site  Description 

Site  Location 

CFBL-net 

0-255 

Reserved  for  CFBL-Net  sites  allocated 
by  CFBL-net  authorities  during 
initiative  setup 

JWC 

301 

NATO  Joint  Warfare  Center 

Stavanger,  Norway 

JFTC 

302 

NATO  Joint  Force  Training  Center 

Bydgoszcz,  Poland 

NC3A 

303 

NATO  Command,  Control  and 
Consultation  Agency 

the  Hague,  the  Netherlands 

ESP  NETN  HUB 

400- 

499 

Series  allocated  for  Spanish  Sites 

Spain 

ITM  Simulation  Lab. 

401 

Institute  of  Technology  "La  Maranosa" 
Simulation  Laboratory 

Madrid,  Spain 

The  Netherlands 

500-599 

Series  allocated  for  Dutch  Sites 

The  Netherlands 

TNO 

501 

TNO 

The  Hague,  Netherlands 

Germany 

600-699 

Series  allocated  for  German  Sites 

Germany 

Sweden 

700-799 

Series  allocated  for  Swedish  Sites 

Sweden 

USA 

800- 

899 

Series  allocated  for  US  sites 

USA 

USJFCOM 

801 

US  Joint  Forces  Command 

Suffolk  VA,  USA 

France 

900-999 

Series  allocated  to  France 

France 

UK 

1000- 

1099 

Series  allocated  to  UK 

UK 

Bulgaria 

1100- 

1199 

Series  allocated  to  Bulgaria 

Bulgaria 

Hungary 

1200- 

1299 

Series  allocated  to  Hungary 

Hungary 

Australia 

1300- 

1399 

Series  allocated  to  Australia 

Australia 

Turkey 

1400- 

1499 

Series  allocated  to  Turkey 

Turkey 

Romania 

1500- 

1599 

Series  allocated  to  Romania 

Romania 

3. 5  Sim ulation  Infrastructure 

NETN  based  federations  are  based  on  STANAG  4603  which  states  that  High-Level  Architecture  (HLA)  IEEE  1516 
shall  be  used  as  the  standard  for  developing  and  federating  simulation  systems.  The  NETN  Reference  Federation 
Agreements  allows  non-HLA  or  legacy  HLA  (i.e.  HLA  1.3)  federates  to  participate  in  the  simulation  using 
appropriate  bridging  and/or  adapter  technologies.  NETN  based  federations  use  the  latest  version  of  IEEE  1516 
(currently  IEEE  1516-2010,  a.k.a.  HLA  Evolved). 


3,5,1  Federations  and  RTIs 

A  NETN  based  federation  shall  run  a  core  federation  based  on  an  IEEE  1516  compliant  and  certified  Runtime 
Infrastructure  (RTI).  Any  bridging  required  in  order  to  adapt  federates  to  IEEE  1516  or  the  selected  RTI  shall  be 
the  responsibility  of  integrating  federate. 

This  Reference  FAD  does  not  specify  a  specific  RTI  implementation  for  use  in  NETN  based  federations.  Several 
certified  RTI  implementations  exist  that  can  provide  the  IEEE  1516  services  to  participating  federates.  In  some 
cases  multiple  NETN  based  federations  may  exist  and  information  between  them  exchanged  using 
bridges/filters/guards  etc. 

All  federations  that  exist  to  support  an  NETN  federation  execution  must  be  clearly  defined.  Agreements  related 
to  the  naming  of  federations,  hosting  of  RTIs  and  specific  details  with  respect  to  RTI  settings  must  be  declared 
as  part  of  the  federation  specific  agreements. 

The  following  template  shall  be  used  to  document  all  relevant  federations  including  at  minimum  the  primary 
HLA  IEEE  1516  based  NETN  federation  and  supporting  RTI. 


Federation 

Name 

RTI  Version 

RTI  Host/Name 

RTI  Port 

Comment 

RID 

<Name> 

<Version> 

<IP  or  Name  of  CRC> 

<CRC  Port> 

<Description> 

<RTI  settings> 

3.6  Federates 

All  federates  participating  in  a  NETN  Federation  must  be  clearly  identified  and  described.  Agreements  with 
respect  to  federates  include: 

•  Federate  Name  (used  in  HLA  IEEE  1516-2010  based  federations  and  may  be  different  from  federate  type) 

•  Federate  Type 

•  Federate  Application  Name  and  Id  (name  of  the  application  hosting  the  federate,  note  that  the  same 
application  can  host  several  federates,  e.g.  a  bridge  application) 

•  Application  ID  -  The  application  Id  is  used  when  exchanging  information  to  create  unique  identifiers 
assigned  to  entities.  The  ID  is  used  in  the  RPR-FOM  datatype  “Entityldentifier" . 

•  Interface  used  to  connect  to  the  RTI  (e.g.  HLA  1.3,  IEEE  1516-2010  ...) 

•  Federation  Name  (the  name  of  the  federation  which  the  federate  joins) 

•  Description  (Information  about  the  main  role  in  the  exercise  and  any  additional  important  information) 

•  Federate  POC  (Org  or  person  responsible  for  the  federate) 


Federate 

Name 

Federate 

Type 

Federate 

Application 

Application 

ID 

Interface 

Federation 

Name 

Description 

POC 

<Name> 

<Version> 

<App 

Name> 

ID 

<lnterface> 

<Federation> 

<Description> 

<POC 

info 

For  clarity,  a  figure  describing  all  federates  connected  in  a  federation  (so-called  lollipop  picture)  should  be 
included  in  the  federation  agreements. 


Example: 


tAHitarj  qn 


Each  federate  should  also  document  their  HLA  interface  in  terms  of  which  HLA  services  are  used  and  which 
information  is  exchange  in  the  federation.  A  Simulation  Object  Model  (SOM),  SOM  Modules  and/or  other 
descriptions  of  the  object  model  used  to  exchange  information  in  the  federation  shall  be  clearly  documented. 
HLA  federate  certification  is  recommended  and  may  be  required. 

3. 7  Supporting  Software  and  Services 

Simulation  Support  Services  are  processes  (software)  which  must  be  executed  in  parallel  to  the  federate 
processes  to  enable  a  federation  execution  or  which  is  required  to  support  individual  simulations  in  the 
federation  to  enable  them  to  participate  in  a  federation  according  agreements. 

NETN  Reference  Architecture  does  not  include  any  specific  Simulation  Support  services. 

•  All  federates/simulations  in  a  NETN  based  federation  must  specify  any  Simulation  Support  services 
used. 

•  The  federation  specific  FAD  shall  document  all  Simulation  Support  services  for  all  participating 
federates 

Examples 

•  Local  RTI  Component  (LRC)  is  an  integral  part  of  the  Federate  Application  and  is  usually  started  in  the 
same  process  space  as  the  federate  itself.  Usually  this  service  is  not  documented  explicitly  in  the  FAD 
unless  the  LRC  does  more  than  expected  like  loading  a  plug-in  for  SOM  to  FOM  translation. 

•  Central  RTI  Component  (CRC).  Unless  running  a  connectionless  RTI  mode  this  component  represents 
the  RTI  Executive  and  is  the  initial  point  of  access  to  a  federation. 

•  Web  Service  Provider  RTI  Component  (WSPRC)  is  an  RTI  component  used  when  offering  the  RTI 

•  Services  using  the  standard  IEEE  1516  Web-Service  API. 


Execution  Control  /  starter  daemons  for  remote  start  up  of  the  CRC,  federates  /  simulation 
applications,  or  the  various  database  services  that  can  be  required  to  run  a  simulation. 
Bridging/gateway/adapter  services  (either  as  a  bi-directional  transfer  or  as  a  data  diode.) 
o  HLA  1.3  <->HLA  IEEE  1516 
o  FOM  X  <->  FOM  Y 
o  DIS  <->  HLA 
o  TENA  <->  HLA 
o  RTI  X  <->  RTI  Y 
o  SIMPLE  <->  HLA  LINK  16  BOM 
Databases  to  provide  initialization  data 
Web-services  to  provide  initialization  data 

Databases  to  provide  weapon-system-parameters  or  material  data 


4  Information  Exchange  Agreements 


4.1  Information  Exchange  Data  Models 

NETN  Federations  use  the  modular  FOM  concept  defined  in  IEEE  1516-2010.  The  modules  describe  how  data  is 
represented  and  encoded/decoded  when  exchanged  in  an  HLA  federation.  The  modular  concept  allows 
federates  to  load  only  those  modules  they  are  aware  of  and  use.  In  addition  the  modules  can  be  extended  with 
more  detailed  representation  by  creating  new  modules  and  sub-classing/using  information  from  other 
modules. 

In  an  NETN  federation  agreement  all  federates  shall  be  documented  with  respect  to  which  FOM  modules  they 
use.  In  addition  each  federate  shall  also  document  a  Simulation  Object  Model  (SOM)  describing  in  detail  what 
parts  of  the  FOM  modules  are  used. 

The  NETN  Reference  Federation  Agreements  Document  have  developed  and  identified  a  set  of  FOM  Modules 
to  support  some  specific  aspects  of  information  exchange  between  federates  in  an  NETN  federation.  Future 
versions  of  this  document  may  include  references  to  more  and/or  updated  modules  that  represent  other 
aspects  currently  not  included  in  the  scope  of  NETN  Reference  Architecture. 

The  NETN  Reference  FOM  is  a  set  of  independent  and  dependent  FOM  Modules.  Each  FOM  Module  is  either  an 
already  established  standard  maintained  by  other  organizations/communities  or  defined  as  a  NETN  FOM 
Module. 

The  following  FOM  Modules  versions  constitute  the  current  version  1.0  of  the  NETN  Reference  FOM: 


FOM  Module 

Dependencies 

Comment 

RPR-FOM  v2.0  D17  (r2) 

Standalone 

The  RPR-FOM  Module  is  based  on  the 
SISO  RPR-FOM  PDG  release  of  RPR-FOM 

v2.0  D17. 

Link  16  FOM  Module  vl.O  D2  (r2) 

RPR-FOM  v2.0  D17 

The  Link  16  FOM  Module  is  based  on 
the  SISO  Linkl6  PDG  work  and  release 
of  Link  16  BOM  vl.O  Draft2. 

NETN  Service  Consumer-Provider 

FOM  Module  vl.O 

Standalone 

The  NETN  Service  Consumer-Provider 

FOM  Module  is  a  base-module  intended 
to  be  extended  to  support  the  modeling 
of  different  types  of  services. 

NETN  Logistics  FOM  Module  vl.O 

NETN  Service  Consumer- 
Provider  FOM  Module  v  1.0, 
NETN  Aggregate  FOM 

Module  vl.O, 

RPR-FOM  v2.0  D17 

The  NETN  Logistics  Module  is  used  to 
model  logistics  services  such  as 
transport,  supply  and  repair. 

NETN  Aggregate  FOM  Module  vl.O 

RPR-FOM  v2.0D17(r2) 

NETN  Service  Consumer- 
Provider  FOM  Module  v  1.0 

The  NETN  Aggregate  FOM  Module 
extends  the  RPR-FOM  representation  of 
Aggregate  and  Platform  entities. 

NETN 

Logistics 

NETN  Aggregate  Unit 

Link  16 

BOM 

1  1 

!  Federation  Execution  Control  ■ 

1  i 

|  and  Monitorina  j 

— 

Transfer 

of 

Modeling 

Responsi 

bilities 

NETN 

ServiceConsumer- 

Real-time  Platform  Reference  (RPR)  -  Federation  Object  Model 

(FOM) 

All  FOM  modules  can  also  be  obtained  as  HLA  IEEE-1516-2010  OMT  Data  Interchange  Format  files. 

Federations  may  extend  the  reference  FOM  with  additional  FOM  Modules  when  appropriate.  The  basic 
FOM  Module  rules  as  defined  in  IEEE  1516-2010  shall  be  applied. 

The  name  of  object-  and  interaction  classes  in  FOM  Modules  developed  specifically  for  NETN  are  prefixed 
NETN_.  When  extending  the  FOM  with  additional  modules  the  naming  of  classes,  datatypes  and  other 
identifiers  should  be  de-conflicted. 

Registered  objects  and  interactions  are  always  discovered/received  at  the  most  specific  subscribed  class 
level.  Extending  a  FOM  Module  with  additional  subclasses  provides  the  possibility  to  add  extra 
attributes/  parameters  at  the  more  specific  class  level.  Exchange  of  information  using  this  more  specific 
level  can  take  place  between  federates  publishing  and  subscribing  to  this  level.  However,  to  become 
compatible  with  and  receive  information  from  federates  only  publishing  on  the  more  general  level,  the 
receiving  federate  must  subscribe  to  both  class  levels.  Subscribers  of  the  more  general  class  will  receive 
information  from  publishers  of  the  more  specific  class  level. 

Example:  A  national  extension  to  the  NETN  FOM  Modules  subclasses  existing  NETN  object 
classes  and  defines  additional  attributes.  National  models  aware  of  this  extension  can  publish 
and  subscribe  to  the  more  specific  level  defined  in  the  national  FOM  module  extensions.  Other 
existing  federates  not  aware  of  the  extension  can  still  discover  the  object  and  receive  updates 
but  only  on  the  level  it  subscribes  to.  In  order  for  the  national  federates  to  discover  and  receive 
information  from  other  federates  they  need  to  subscribe  to  the  NETN  class  level  as  well  as  the 
national  extension  level.  Be  aware  that  the  discovered  object  and  attribute  updates  will  be  on 
the  NETN  level. 

4.2  Platforms  and  Aggregate  Units 

Information  about  Platforms  and  Aggregate  Units  are  exchanged  in  NETN  Federations  using  the  RPR- 
FOM  v2.0  D17  FOM  Module  and  extensions  represented  in  the  NETN  Aggregate  FOM  Module  vl.O. 

The  NETN  Aggregate  FOM  Module  vl.O  extends  the  representation  available  in  the  RPR-FOM  with 
additional  information  enabling  a  higher  level  of  interoperability  between  systems  using  these 
extensions.  The  NETN  Aggregate  FOM  Module  vl.O  is  documented  in  chapter  9. 

Mixing  federates  working  on  the  basic  RPR-FOM  level  with  the  more  detailed  NETN  Aggregate  FOM 
Module  level  is  possible  and  allowed  depending  on  the  requirements  of  the  federation  in  terms  of 
interoperability.  E.g.  a  federate  only  requiring  RPR-FOM  information  can  subscribe  to  information  on 
that  level  while  other  federates  exchange  information  on  the  NETN  Aggregate  FOM  Module  level. 

4.2.1  Entity  Identifier 

In  the  federation  agreements  all  known  units  and  platforms  shall  have  a  unique  identifier  associated  with 
the  entity.  In  addition  initial  information  about  the  state  of  the  entity  shall  be  documented.  This  includes 


the  following  RPR-FOM  and  NETN  Aggregate  FOM  Module  information.  Callsign  (Who),  Entity  Type 
(What),  Spatial  (Where),  Marking. 


4.2.2  Entity  Types 

The  RPR-FOM  also  requires  an  agreement  with  respect  to  platform  and  aggregate  unit  entity  types.  A  key 
attribute  of  simulated  entities  and  units  are  that  they  have  entity  type  identifiers.  In  RPR-FOM  this  is  a  7 
digit  code  representing  the  Kind,  Domain,  Country,  Category,  Subcategory,  Specifics  and  Extra 
information  to  define  the  type  of  a  platform  or  unit.  There  exists  standards  that  document  common 
platform  and  unit  types  however  for  a  specific  federation  agreements  related  to  Entity  Types  must  be 
documented. 

All  known  entity  types  that  will  be  represented  in  the  federation  shall  be  defined  and  listed  in  the 
federation  agreements.  Federates  supporting  a  subset  of  the  identified  types  shall  list  those  types 
supported. 

4.2.3  Symbols 

In  many  federations  there  is  a  requirement  to  correlate  the  symbols  used  to  represent  platforms  and 
units  on  2D  and/or  3D  displays.  Such  agreements  shall  be  documented  in  the  federation  agreements  as 
mappings  between  Entity  Types  and  Symbols.  Other  information  required  to  map  to  symbols  may  be 
Forceldentifier  and  unit  size  information. 

4.3  Modeling  Responsibilities 

In  a  federation  the  responsibility  of  modeling  and  simulation  of  the  synthetic  environment  is  distributed. 
Each  federate  have  intrinsic  capabilities  to  represent  certain  aspects  of  entities,  events  and  other 
phenomenon  in  the  simulated  environment.  During  federation  design  the  roles  and  responsibilities  of  all 
federates  are  described  and  documented.  The  responsibility  of  modeling  certain  aspects  can  only  be 
assigned  to  a  federate  with  a  capability  that  meets  specified  requirements.  Initial  modeling 
responsibilities  and  capabilities  of  dynamically  transferring  modeling  responsibilities  shall  be 
documented  in  the  federation  agreements. 

4.3.1  Services  Modeling 

The  NETN  Reference  Federation  Agreements  includes  FOM  modules  to  federate  to  provide  modeling  and 
simulation  as  services  to  other  federates.  This  is  not  a  transfer  of  responsibility  between  federates  but 
rather  a  service  provided  by  one  federate  and  consumed  by  another.  The  NETN  Service-Consumer  FOM 
Module  vl.O  is  a  base  module  that  allows  federates  to  request,  provide  and  consume  services.  In 
addition  a  NETN  Logistics  FOM  module  is  provided  specifically  for  logistics  related  services. 

Services  Modeling  is  the  preferred  method  by  which  a  federate  transfers  resources  (Supply),  transports 
(Convoy)  and  or  provides  maintenance  (Repair)  units  and  platforms  simulated  in  another  system. 

The  NETN  Service-Consumer  FOM  Module  is  provided  in  chapter  7  and  the  NETN  Logistics  FOM  Module 
is  provided  in  chapter  8. 

4.3.2  Dynamic  Transfer  of  Modeling  Responsibilities 

No  design  pattern  for  the  dynamic  transfer  of  modeling  responsibilities  has  been  verified  as  part  of  the 
MSG-068  NETN  work  and  no  such  module  is  included  in  this  document.  However  there  exist  proposals 
that  may  be  included  in  future  versions  of  this  document. 


4.4  Radio  Simulation  Agreements 

Radio  simulation  in  NETN  based  federation  shall  use  the  RPR-FOM  (DIS)  Radio  protocol/interactions. 


5  RPR-FOM  v2.0  D17  (r2)  FOM  Module 

The  NETN  Reference  FOM  and  FAD  are  dependent  on  the  Standard  Real-Time  Platform  Reference  FOM. 
The  version  used  is  currently  under  development  by  the  Simulation  Interoperability  Standards 
Organization  (SISO)  in  a  Product  Development  Group  (PDG).  The  version  selected  is  widely  used  by 
industry  and  a  well  know  de-facto  standard. 

Recommendations: 

Use  the  NETN  Logistics  FOM  Module  services  approach  and  not  the  RPR-FOM  logistics 
interactions 

Use  the  extended  NETN  Aggregate  FOM  Module  representation  of  platforms  and  Aggregate 
Entities 


6  Link  16  FOM  Module 


The  Link  16  FOM  module  is  a  derivate  from  the  SISO-STD-002-2006:  Standard  for:  Linkl6  Simulations 
(aka.  Linkl6  BOM)  and  is  dependent  on  the  Standard  Real-Time  Platform  Reference  FOM. 

The  Link  16  BOM  is  available  from  SISO.  It  has  been  adapted  to  a  FOM  Module,  dependent  on  the  RPR- 
FOM  v2.0. 


7  NETN  Service  Consumer-Provider  FOM  Module 


7.1  Introduction 

This  document  describes  a  basic  pattern  for  modeling  request,  negotiation  and  delivery  of  services.  The 
interaction  patterns  required  for  different  types  of  services  may  vary  but  the  basic  principles  and 
interaction  class  definitions  are  outlined  in  this  chapter. 

In  the  RPR-FOM  and  DIS  patterns  exist  to  model  logistics  services.  The  intention  is  to  allow  these  specific 
patterns  to  map  onto  the  more  general  Service  Consumer-Provider  Pattern.  This  is  described  in  more 
detailed  in  the  Logistics  FOM  Module  chapter. 

The  Service  Consumer-Provider  Pattern  defines  two  types  of  entities. 

•  Service  Consumer  Entities:  are  entities  requesting  and  consuming  specific  services  offered  and 
provided  by  other  entities. 

•  Service  Provider  Entities:  are  entities  able  to  offer  and  provide  a  specific  service. 

A  provider/consumer  entity  can  be  of  various  kinds,  e.g.: 

•  An  object  instance  in  a  federation  execution 

•  A  federate 

•  A  controller  of  a  function  implemented  in  a  federate  application 

The  interactions  between  entities  in  this  pattern  will  be  published  and  sent  using  HLA  services. 

7.2  General  Approach 

The  pattern  is  divided  into  three  phases: 

1.  Service  Negotiation:  the  service  is  requested,  offers  received  and  offers  are  either  accepted  or 
rejected. 

2.  Service  Delivery:  the  consumer  indicates  that  it  the  deliver  process  can  start  and  the  selected 
provider  start  delivering  and  continues  until  all  service  has  been  delivered. 

3.  Service  Acceptance:  the  provider  or  consumer  indicates  the  completion  of  the  service  delivery 
and  waits  for  acknowledgment/acceptance  from  the  other  part. 
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The  above  interaction  diagram  shows  the  normal  patterns  for  requesting  services  and  receiving 
notification  that  the  service  transaction  has  completed. 

Variations  include: 

•  Service  completion  is  determined  by  the  consuming  entity  and  sent  as  a  NETN_ServiceReceived 
interaction  before  the  corresponding  NETN_ServiceCompleted  interaction  is  sent. 

•  The  service  offer  (NETN_OfferService)  is  NOT  proceeded  by  a  service  request.  This 
accommodates  cases  in  which  a  service  provider  determines  that  a  service  is  needed  by  one  or 
more  consumers 

•  and  offers  that  service  before  being  asked 
Exceptions  include: 


•  Early  termination  of  the  service  by  either  the  consumer  or  provider  using  the 

NETN_CancelService 

•  interaction 

•  Rejection  of  service  offer  by  the  service  consumer  entity  using  the  NETN_RejectOffer  interaction. 
Federation  agreements: 

The  condition  for  offering  a  service  based  on  information  in  the  request  is  an  agreement  for  a  specific 
federation.  This  agreement  shall  be  documented  in  the  federation  specific  agreements  using  the 
following  reference  template: 


Scope/type  of  request  Condition  for 

Offering 

All  types  of  requests  exactly 

Ability  to  provide  the  type  of  service  must  match 

<scope> 

<condition> 

Extending  the  RequestSupply  and  adding  parameters  with  description  of  the  conditions  for  offering  may 
be  a  future  extension,  e.g.  in  a  RequestSupply  the  requested  supplies  (amount,  type)  needs  to  be 


available  by  a  producer  in  order  to  make  an  offer.  On  the  other  hand  one  might  also  consider  providers 
making  promises  they  know  or  don't  know  they  cannot  keep  (like  in  real  life). 

7,2,1  Service  Consumer 

It  is  usually  the  service  consumer  that  initiates  a  request  for  a  specific  service.  A  service  consumer  can  be 
engaged  in  several  concurrent  service  requests  and  deliveries.  For  each  requested  service  the  state  of 
the  service  consumer  can  be  described  using  a  state-transition  diagram  (STD). 

The  Service  Consumer  entity  may  be  in  one  of  four  states  with  respect  to  a  requested  service: 


•  Requesting  state.  A  service  consumer  entity  is  in  the  Requesting  State  when  it  has  requested  a 
specific  service  from  another  entity 

•  Offered  state.  A  service  consumer  entity  is  in  the  Offered  State  when  an  offer  of  the  service 
delivery  has  been  made  by  a  service  provider 

•  Contracted  state.  A  service  consumer  entity  is  in  the  Contracted  State  when  an  offer  has  been 
accepted 

•  Waiting  State.  A  service  consumer  is  ready  to  receive  the  service  and  waiting  for  service  delivery 
start 

•  Receiving  state.  A  service  consumer  entity  is  in  the  Receiving  State  during  service  delivery 


Transition 

Condition  and  Actions 

Request  Service 

When  conditions  for  requesting  a  service  are  met,  the  consuming  entity 

shall  issue  a  NETN_RequestService  interaction.  The 

entity  shall  proceed  from  the  Initial  state  to  the  Requesting  state 

Cancel  Request 

When  conditions  for  requesting  the  services  are  no  longer  met  a 
NETN_CancelService  interaction  is  sent  and  the  entity  proceed  from 
the  Requesting  state  to  the  End  state 

Receive  a  no  Offer 

When  a  NETN_OfferService  with  a  NoOffer  indication  is  received,  the 
entity  shall  proceed  from  the  Requesting  state  to  the  End  state 

Receive  Offer 

When  a  NETN_OfferService  with  an  Offer  indication  is  received,  the 
entity  shall  proceed  from  the  Requesting  state  or  Initial  state  to  the 
Offered  state 

Reject  Offer 

When  conditions  for  accepting  a  service  offer  are  not  met  the  service 
consuming  entity  shall  issue  a  NETN_RejectOffer  interaction  and 
proceed  to  the  End  state 

Accept  Offer 

Accept  offer  When  conditions  for  accepting  a  service  offer  exists  the 
service  consuming  entity  shall  issue  a  NETN_AcceptOffer  interaction 
and  proceed  to  the  Contracted  State 

Ready  to  Receive  Offer 

When  conditions  for  delivery  of  the  service  are  met  the  service 
consuming  entity  shall  issue  a  NETN_ReadyToReceiveOffer  interaction 
and  proceed  to  the  Waiting  State 

Cancel  Service 

When  conditions  for  receiving  the  services  are  no  longer  met  a 
NETN_CancelService  interaction  is  sent  and  the  entity  proceed  to  the 

End  State 

Service  Canceled 

When  a  NETN_CancelService  interaction  is  received  the  service 
consuming  entity  shall  proceed  to  the  End  State 

Start  Service  Delivery 

When  an  NETN_ServiceStarted  interaction  is  received  the  service 
consuming  entity  shall  proceed  to  the  Receiving  State 

Service  Completed 

When  a  NETN_ServiceCompleted  interaction  is  received  or  when  the 
consuming  entity  determines  that  the  conditions  for  service  completed 
are  met  the  NETN_ServiceReceived  interaction  shall  be  sent  and  the 
entity  shall  proceed  to  the  End  State 

7.2.2  Service  Provider 

The  Service  Provider  entity  may  be  in  one  of  four  states  with  respect  to  a  requested  service: 

•  Requested  State.  A  service  producer  entity  is  in  the  Requested  State  when  it  has  received  a 
request  for  a  service  from  a  service  consumer  entity 

•  Offering  State.  A  service  provider  entity  is  in  the  Offering  State  when  an  offer  in  response  to  a 
requested  service  has  been  delivered  to  a  service  consumer 

•  Contracted  State.  A  service  provider  entity  is  in  the  Contracted  State  when  its  offer  has  been 
accepted 

•  Preparing  State.  A  service  consumer  has  indicated  it  ready  to  receive  the  service,  a  service 
provider  prepares  the  service  delivery 

•  Servicing  state.  A  service  provider  entity  is  in  the  Servicing  state  when  a  service  is  being 
delivered  to  a  service  consuming  entity 
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Service  Completed 


Transition 

Condition  and  Actions 

Service  Requested 

When  a  NETN_RequestService  is  received  the  service 
providing  entity  shall  proceed  from  the  initial  state  to  the 
Requested  State 

Cancel  Request 

When  a  NETN_CancelService  interaction  is  received  from  a 
service  consuming  entity,  the  entity  shall  proceed  from  the 
Requested  State  to  the  End  State 

No  Offer 

When  the  conditions  for  delivering  a  requested  service  are 
not  met,  a  NETN_OfferService  with  a  NoOffer  indication 
shall  be  sent  and  the  service  producing  entity  shall 
proceed  to  the  End  State 

Offer 

When  the  conditions  for  delivering  a  requested  service  are 
met,  a  NETN_OfferService  including  the  offer  shall  be  sent 
and  the  service  producing  entity  shall  proceed  to  the 
Offering  State 

Offer  Rejected 

When  a  NETN_RejectOffer  is  received  the  service 
producing  entity  shall  proceed  to  the  End  State 

Offer  Accepted 

When  a  NETN_AcceptOffer  is  received  the  service 
producing  entity  shall  proceed  to  the  Contracted  State 

Service  Ready  to  Receive 

When  a  NETN_ReadyToReceiveService  is  received  the 
service  producing  entity  shall  proceed  to  the  Preparing 

State 

Cancel  Service 

When  conditions  for  receiving  the  services  are  no  longer 
met  a  NETN_CancelService  interaction  is  sent  and  the 
entity  proceed  to  the  End  state 

Transition 

Condition  and  Actions 

Service  Canceled 

When  conditions  for  providing  the  services  are  no  longer 
met  a  NETN_CancelService  interaction  is  sent  and  the 
entity  proceed  to  the  End  state 

Start  Service  Delivery 

When  the  conditions  for  starting  the  service  delivery  is 
met,  a  NETN_ServiceStarted  interaction  is  sent  and  the 
service  providing  entity  proceeds  to  the  Servicing  state 

Service  Completed 

When  a  NETN_ServiceReceived  interaction  is  received  or 
when  the  conditions  for  completed  service  delivery  is  met, 
a  NETN_ServiceCompleted  interaction  is  sent  and  the 
service  producing  entity  proceeds  to  the  End  state 

7.3  Interaction  Classes 

The  Service  Consumer-Provider  Pattern  defines  a  set  of  HLA  interaction  classes  used  to  implement  the 
three  phases  of  the  pattern.  These  interactions  are  provided  as  a  FOM  Module  and  can  be  extended  to 
support  specific  service  types. 


Class  1 

Class  2 

NETN Service 

NETN RequestService 

NETN OfferService 

N  ETN Acce  ptOff  e  r 

NETN RejectOffer 

NETN CancelService 

NETN ReadyToReceiveService 

N  ETN Se  rviceSta  rted 

NETN ServiceCompleted 

NETN ServiceReceived 

7.3,1  NETN_Service 

The  NETN_Service  interaction  class  is  the  base  class  for  all  NETN  Service  Consumer-Provider  Pattern 
interactions.  It  contains  the  basic  required  parameters  (not  optional)  that  are  always  sent. 

Full  Name:  HLAinteractionRoot.NETN  Service 


Parameter 

Data  type 

Default  value 
(if  optional) 

Definition 

ServicelD 

NETN Eventldentifier 

(Not  Optional) 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

(Not  Optional) 

Requesting  entity 

Provider 

NETN Callsign 

(Not  Optional) 

Providing  or  intended  provider  entity 

ServiceType 

NETN ServiceTypeEnum8 

(Not  Optional) 

Extension  of  RPR2  ServiceTypeEnum8 

The  NETN_ServiceTypeEnum8  enumerated  data  type  is  an  extension  of  the  ServiceTypeEnum8  defined 
in  the  RPR-FOM  v2.0. 


7.3.2  NETN_RequestService 

The  request  for  a  service  is  always  initiated  by  a  NETN_RequestService.  Subclasses  of  this  interaction  for 
specific  types  of  services  may  include  parameters  for  detailing  the  requirements  of  this  request.  This  may 
include  information  when,  where  and  how  the  service  is  to  be  delivered. 

Full  Name:  HLAinteractionRoot.NETN_Service.NETN_RequestService 


Parameter 

Data  type 

Default  value 
(if  optional) 

Definition 

RequestTimeOut 

NETN_lnteger64BE 

0 

Defined  a  deadline  (date)  for  the 
provider  response.  Number  of  second 
since  01/01/1970. 

Default  value  zero  (0)  implies  that  the 
time  out  value  has  no  meaning 

7.3.3  NETN.OfferService 

The  NETN_OfferService  is  usually  a  response  to  a  NETN_RequestService  and  contains  information  with 
respect  to  the  providing  entities  ability  to  deliver  the  requested  service.  This  ability  is  expressed  as  either 
an  offer  to  provide  the  service  or  no  offer.  Subclasses  of  this  interaction  for  specific  types  of  offers 
should  contain  more  detailed  description  of  the  offer.  This  may  include  information  about  when,  where, 
how  the  service  can  be  delivered. 

Full  Name:  HLAinteractionRoot.NETN  Service.NETN  OfferService 


Parameter 

Data  type 

Default 

value 

(if 

optional) 

Definition 

IsOffering 

HLAboolean 

(Not 

Optional) 

Defines  if  the  requested  service  is  offered 
(=true)  or  not  (=false) 

RequestTimeOut 

NETN_lnteger64BE 

0 

Defined  a  deadline  (date)  for  the  consumer 
response.  Number  of  second  since 
01/01/1970. 

Default  value  zero  (0)  implies  that  the  time 
out  value  has  no  meaning 

7.3.4  NETN.AcceptOffer 

The  NETN_AcceptOffer  is  used  to  accept  an  offer  made  by  a  service  providing  entity  as  indicated  in  a 
NETN_OfferService  interaction.  By  issuing  a  NETN_AcceptOffer  interaction  the  service  consuming  entity 
enters  a  contract  for  service  delivery  with  the  service  producing  entity. 

Full  Name:  HLAinteractionRoot.NETN_Service.NETN_AcceptOffer 

The  NETN_AcceptOffer  interaction  does  not  define  any  additional  parameters  but  subclasses  may 
include  parameters  with  additional  information. 

7.3.5  NETN_Re j ectOffer 

The  NETN_RejectOffer  is  used  to  reject  an  offer  made  by  a  service  providing  entity  as  indicated  in  a 
NETN_OfferService  interaction.  By  issuing  a  NETN_RejectOffer  interaction  the  service  consuming  entity 
informs  the  providing  entity  that  the  offer  has  been  rejected. 

Full  Name:  HLAinteractionRoot.NETN_Service.NETN_RejectOffer 


The  NETN_RejectOffer  interaction  does  not  define  any  additional  parameters  but  subclasses  may  include 
optional  parameters  for  detailing  the  reasons  for  rejecting  the  service. 

7,3,6  NETN_CancelService 

The  NETN_CancelService  interaction  is  used  by  either  a  service  consuming  entity  or  a  service  providing 
entity  to  inform  about  early  termination  of  the  service  delivery  or  in  some  cases  termination  of  the 
service  request  before  delivery  has  begun. 

Full  Name:  HLAinteractionRoot.NETN_Service.NETN_CancelService 

The  NETN_CancelService  interaction  does  not  define  any  additional  parameters  but  subclasses  may 
include  optional  parameters  for  detailing  the  reasons  for  canceling  the  service. 

7-3-7  NETN_ReadyToReceiveService 

The  NETN_ReadyToReceiveService  interaction  is  issued  by  a  service  consuming  entity  to  indicate  that 
the  start  of  service  delivery  can  start.  The  time  of  service  delivery  start  may  be  significantly  later  then 
indicating  ready  for  service  delivery. 

Full  Name:  HLAinteractionRoot.NETN_Service.NETN_ReadyToReceiveService 

The  NETN_ReadyToReceiveService  interaction  does  not  define  any  additional  parameters. 

7-3-8  NETN_ServiceStarted 

The  NETN_ServiceStarted  interaction  is  issued  by  a  service  providing  entity  to  inform  about  the  start  of 
service  delivery.  The  time  of  service  delivery  start  may  be  significantly  later  then  receiving  a  indication 
from  the  consumer  that  the  service  delivery  can  start. 

Full  Name:  HLAinteractionRoot.NETN_Service.NETN_ServiceStarted 

The  NETN_  ServiceStarted  interaction  does  not  define  any  additional  parameters. 

7-3-9  NETN_ServiceCompleted 

The  NETN_ServiceCompleted  interaction  is  used  by  a  service  providing  entity  to  inform  the  service 
consuming  entity  that  the  service  has  been  delivered. 

Full  Name:  HLAinteractionRoot.NETN_Service.NETN_ServiceCompleted 

The  NETN_  ServiceCompleted  interaction  does  not  define  any  additional  parameters. 

7-3-10  NETN_ServiceReceived 

The  NETN_ServiceReceived  interaction  is  used  by  a  service  consuming  entity  to  inform  the  service 
providing  entity  that  the  service  has  been  delivered. 

Full  Name:  HLAinteractionRoot.NETN_Service.NETN_ServiceReceived 

The  NETN_  ServiceReceived  interaction  does  not  define  any  additional  parameters. 


7.4  Simple  Datatypes 


Name 

Representation 

Semantics 

NETN lnteger64BE 

HLAinteger64BE 

NETN lnteger32BE 

HLAinteger32BE 

NETN lntegerl6BE 

HLAintegerl6BE 

Name 

Representation 

Semantics 

NETN Float64BE 

HLAfloat64BE 

NETN Float32BE 

HLAfloat32BE 

7.5  Arrays 


Name 

Representation 

Encoding 

Semantics 

NETN Callsign 

HLAunicodeString 

HLAvariableArray 

7.6  Fixed  Records 


7.6.1  NETN.Eventldentifier 


gVIame 

NETN Eventldentifier 

Encoding 

HLAfixedRecord 

Semantics 

- 

Field  Name 

Type 

Semantics 

EventCount 

NETN lnteger32BE 

IssuingObjectldentifier 

NETN Callsign 

7. 7  Enumerated  Datatypes 


7.7.1  NETN_ServiceTypeEnum8 


Name 

NETN ServiceTypeEnum8 

Representation 

HLAoctet 

Semantics 

- 

Enumeration 

Value 

Semantics 

Other 

0 

Resupply 

1 

Repair 

2 

Storage 

3 

Convoy 

4 

CombatAdjudication 

5 

8  NETN  Logistics  FOM  Module  vl.O 


8.1  Scope 

The  NETN  Logistics  FOM  Module  is  based  on  the  NETN  Service  Consumer-Provider  FOM  Module  with 
extensions  to  support  specific  logistics  services  as  defined  below.  Detailed  description  on  how  these 
services  map  to  the  NETN  Logistics  interactions  are  included  in  this  document. 

The  NETN  Logistics  FOM  Module  is  also  dependent  on  the  RPR-FOM  v2.0  due  to  the  fact  that  several 
data  types  defined  in  the  RPR-FOM  are  reused  in  the  definition  of  parameters  for  logistics  interactions. 

In  addition,  a  Transfer  of  Control  pattern  is  introduced  as  an  option  for  some  logistics  services. 

Extensions  to  existing  RPR-FOM  object  classes  are  proposed. 

The  NETN  Logistics  FOM  Module  covers  the  following  services: 

•  Supply  service  is  provided  by  a  facility,  a  unit  or  any  battlefield  entity  with  consumable  materials 
supply  capability 

•  Storage  service  is  provided  by  a  facility  or  means  of  transportation  capable  of  storing 
consumable  materials 

•  Repair  service  can  be  performed  on  equipment  (i.e.  non-consumables  items  such  as  platforms) 
by  facilities  or  units  capable  of  performing  requested  repairs.  The  repair  service  does  not 
transfer  the  control  of  a  damaged  platform  to  the  repairing  facility 

•  Transport  service  provides  a  means  of  transport  capable  of  storing  and  delivering  non¬ 
consumable  materials.  Materials  are  embarked,  transported  and  disembarked,  with  possible  use 
of  a  Transfer  of  Control  protocol 

•  Embarkment  service  provides  a  means  of  transport  or  a  facility  capable  of  storing  non¬ 
consumable  materials,  with  possible  use  of  a  Transfer  of  Control  protocol 

•  Disembarkment  service  provides  a  means  of  transport  or  a  facility  capable  of  delivering  non¬ 
consumable  materials,  with  possible  use  of  a  Transfer  of  Control  protocol 

Examples  of  uses: 

•  Resupply  of  units  (Consumer)  by  transportation  means 

•  Supply  of  fixed  wings  in  airports  or  during  aerial  refueling 

•  Supply  of  helicopter  in  assembly  areas 

•  Transport  of  troops  by  train,  ship  and  aircraft 

•  Repair  of  damaged  platforms  by  a  maintenance  unit  without  changing  platforms  location 

•  Maintenance  of  damaged  platforms  previously  deposited  in  a  facility 

•  Embarkment  and  disembarkment  of  small  or  large  units 

•  etc. 

8.2  Definitions 

Logistics  supplies  the  troops  with  material  and  carries  out  maintenance. 

Means  of  transport,  transport  resources  and  facilities  for  maintenance  and  storage  are  required  for 
these  tasks. 

The  term  of  unit  will  be  used  for  individual  platform  entities  as  well  as  for  aggregate  entities. 


8.2.1  Materials 

Materials  are  differentiated  between: 

•  Consumable  materials 

o  Ammunition 
o  Mines 
o  NBC  Materials 

o  Fuel  (Diesel,  Gas,  Aviation  fuel,  etc.) 
o  Water 
o  Food 

o  Medical  materials 
o  Spare  parts 

•  Non-consumable  materials 

o  Vehicles 
o  Aggregates 

o  Reconnaissance  and  Artillery  systems  (Radar) 
o  Missile 

The  NETN  Reference  Federation  Agreements  follows  the  RPR  FOM  convention  by  treating  the  above 
non-consumable  materials  as  platform  objects.  Consumable  materials,  hereafter  also  referred  to  as 
supplies,  differ  from  non-consumables  in  that  the  former  can  be  transferred  to  a  federation  object, 
thereby  "resupplying"  that  object  with  the  appropriate  consumable  material.  Consumable  materials  are 
further  differentiated  between  piece  goods  and  bulk  goods  (e.g.  fuel,  water,  decontamination  means). 
Material  may  therefore  be  requested  as  individual  pieces  (each),  or  in  cubic  meters  for  liquid  bulk  goods 
and  kilograms  for  solid  bulk  goods. 

The  type  of  packaging  (fuel  in  canisters,  water  in  bottles,  etc.)  is  not  taken  into  account. 

Note:  Many  types  of  materials  are  often  grouped  together.  Examples  of  this,  taken  from  different 
simulations,  are: 

•  Many  artillery  models  do  not  distinguish  between  propellants,  fuses,  warheads,  etc. 

•  Diesel,  gas,  and  aviation  fuel  are  grouped  together  under  "Fuel". 

•  Medical  material  is  only  roughly  divided  into  different  classes. 

•  The  supply  of  food  and  water  is  not  represented  in  detail. 

Only  damaged  platforms  will  be  delivered  to  maintenance  (repair).  The  required  effort  for  the  repair  of 
damaged  material  is  determined  by  the  provider  model.  It  is  calculated,  based  on  the  degree  of  damage 
to  the  material. 

8.2.2  Means  of  transport 

Depending  on  the  federation,  means  of  transport  are  published  as  platforms  or  as  equipment  of 
aggregate  units.  If  transportation  means  are  used  as  provider  in  the  NETN  Service  Consumer-Provider 
pattern,  they  have  to  be  published  and  registered  as  platforms  objects  in  the  federation.  This  suggested 
approach  does  not  require  the  publishing  of  the  loading  of  the  means. 

For  example,  if  a  means  of  transport  is  to  supply  units,  it  then  proceeds  to  a  depot,  or  is  itself  a  depot. 
Objects  of  other  federates  will  then  be  supplied  from  the  depot  (supply  facility). 


8.2.3  Transport  resources 

The  suggested  transport  resources  are  containers  and  flats.  Depending  on  the  federate  agreements, 
resources  can  be  published  as  platforms.  If  the  transport  resources  are  not  exchanged  between 
federates,  they  do  not  need  to  be  published  within  the  federation. 

8.2.4  Facilities 

Facilities  are  the  central  element  through  which  material  can  be  transferred.  Facilities  may  be  created 
during  a  simulation  or  may  be  a  part  of  the  infrastructure  (railway  station,  storage  tanks  depot,  port, 
etc.).  A  facility  may  be  part  of  a  unit  (e.g.  ship,  etc.). 

8. 3  Transfer  of  Con  trol 

The  main  objective  is  to  provide  Transfer  of  Control  mechanisms  in  support  of  NETN  interactions 
between  federates  collaborating  through  logistics  process. 

8,3,1  Principles  of  Transfer  of  Control 

Transfer  of  Control  is  optional  depending  on  operational  level  of  simulations: 

•  Some  users  will  need  to  transport  whole  entities,  including  Aggregates  units.  It  is  often 
impossible  to  break  down  small  units  like  platoons  or  sections. 

•  Some  others  will  absolutely  need  to  break  down  large  units  like  brigades  or  battalions  (often 
Aggregates),  in  order  to  make  them  transported  and  usable  in  more  than  one  single  position  at 
the  same  time. 

Therefore,  the  use  of  Transfer  of  Control  as  described  in  this  Logistics  FOM  Module  is  not  mandatory. 
Simulations  will  be  able  to  cooperate  with  others,  using  logistics  Convoy  pattern  without  doing  any 
Transfer  of  Control  action. 

In  case  of  not  using  Transfer  of  Control,  a  transported  unit  remains  active  during  transportation.  So 
location  of  the  transported  unit  remains  at  the  embarkment  location  until  disembarkment.  Then,  a  jump 
of  location  at  the  disembarkment  time  occurs.  That  could  cause  an  error  because  another  unit  could 
interact  with  the  transported  one,  considering  its  embarkment  position.  Transportation  can  be  made  in 
one  or  several  trips  by  one  or  several  transporters. 

The  Transfer  of  Control  protocol  described  here  is  not  an  HLA  service. 

From  a  Consumer  point  of  view,  Transfer  of  Control  is  limited  because: 

•  The  unit  is  transferred  to  the  Provider,  but  the  Consumer  conserves  its  property.  The  Consumer 
is  still  in  charge  of  updating  the  unit  (position,  operational  status,  consumptions,  etc.)  with 
obligation  to  declare  an  Active  /  Inactive  status  parameter  (see  below). 

•  The  Consumer  control  on  the  transferred  unit  is  limited  to  "passive"  functions,  e.g.  supply  or 
repair.  Passive  function  implies  no  movement,  combat  or  destruction. 

There  is  no  total  only  limited  Transfer  of  Control  of  an  entity.  The  control  by  the  Provider  applies  only  to 
some  transferred  elements  (or  sub-elements)  of  the  unit. 

Therefore,  a  transporter  (here  Provider)  does  not  directly  use  the  simulated  object  during 
transportation:  entities  or  aggregates  shall  be  represented  by  a  structure  that  gives  main  characteristics 
of  the  embarked  platform(s).  This  is  the  reason  why  a  request  for  Convoy  shall  give  a  list  of  platforms 
(and  their  characteristics)  to  be  transported.  Transporter  shall  then  manipulate  this  list  during 


transportation  and  on  disembarkment  a  platform  simulation  shall  build  a  new  object  that  corresponds  to 
the  list. 

8.3.2  Use  of  an  Active  /  Inactive  status  parameter 

Entities  or  aggregates  shall  have  a  status  parameter  that  defines  if  they  are  "Active"  or  "Inactive"  in  the 
federation  (the  Logistics  FOM  Module  extends  all  RPR-FOM  Platform  Object  Classes  with  this  parameter): 

•  "Active"  is  the  default  status  of  any  element  not  transferred  at  initialization  time.  An  "Active" 
element  can  react  to  the  simulation  environment. 

•  "Inactive"  means  that  an  element  is  not  simulated.  It  does  not  react  to  the  simulation 
environment,  like  a  dead  unit.  Other  federates  following  these  agreements  recognize  its 
aggregate  status  as  deactivated  and  should  not  try  to  interact.  The  HLA  object  of  the  "inactive" 
unit  remains  in  the  federation  and  models  continue  to  subscribe  to  its  HLA  update. 

8.3.3  Disaggregation  of  units  during  transportation 

As  transporters  could  generally  not  transport  a  large  aggregate  unit  in  one  travel,  the  list  of  components 
of  the  aggregate  to  be  transported  (i.e.:  list  of  the  entities  or  sub-aggregates)  should  be  managed  by  the 
consumer  as  non-divisible  components. 

The  Consumer  can  provide  a  list  of  components  (optional)  to  make  the  Transporter  able  to  share  this  list 
in  different  means  of  transport,  with  obligation  to  transport  all  of  it.  If  the  list  of  components  is  not 
provided,  the  Transporter  will  consider  the  transportation  of  this  whole  unit,  in  order  to  accept  or  reject 
this  service  request. 

From  a  Consumer  point  of  view,  to  provide  a  list  of  components  is  recommended  for  units  bigger  than  a 
platoon 

Concerning  entities  management: 

•  During  Embarkment:  when  a  federate  receives  an  EmbarkmentStatus,  it  must  analyze  the 
optional  list  of  embarked  objects.  At  this  step,  the  consumer  federate  must  set  the  entity 
(identified  by  a  callsign)  as  inactive.  The  entity  is  no  more  taken  into  account  in  simulation. 

•  During  Disembarkment:  when  a  federate  receives  a  DisembarkmentStatus,  it  must  analyze  the 
optional  list  of  disembarked  objects.  If  an  object  from  the  list  is  defined  at  entity  level  (see 
description  of  NETN_ArrayOfObjectDefinition),  an  entity  object  shall  be  retrieved  with  the  given 
callsign.  Federate  updates  the  entity  status  as  active,  and  its  location  at  Disembarkment  position. 

•  During  Transport:  combination  of  the  two  previous  items. 

Concerning  aggregates  management: 

•  During  Embarkment:  when  a  federate  receives  an  EmbarkmentStatus,  it  must  analyze  the 
optional  list  of  embarked  objects  and  identify  those  corresponding  to  aggregates,  using  callsigns. 
Federate  can  then  go  through  the  embarked  objects  list  (see  description  of 
NETN_ArrayOfObjectDefinition).  This  complete  or  partial  list  describes  objects  constituting  the 
aggregate.  At  this  step,  federate  has  to  update  the  aggregate  representation  by  removing  the 
identified  objects  from  its  internal  list.  When  federate  receives  an  EmbarkmentEnd  interaction, 
and  if  all  listed  objects  of  the  aggregate  are  removed,  aggregate  is  set  in  an  inactive  state.  Then, 
the  aggregate  could  be  removed  from  the  federation. 

•  During  Disembarkment:  when  a  federate  receives  a  DisembarkmentStatus,  it  must  analyze  the 
optional  list  of  disembarked  objects.  If  an  object  from  the  list  is  defined  at  aggregate  level  (see 
description  of  NETN_ArrayOfObjectDefinition),  it  could  be  necessary  to  create  a  new  aggregate 
object,  defined  as  Bridgehead.  It  must  be  identified  by  a  new  callsign  on  the  federation. 

•  During  Transport:  combination  of  the  two  previous  items. 


8.3.4  Representation  of  "Inactive"  units 

When  the  status  of  a  unit  is  set  as  «  Inactive  »  the  recommended  representation  in  systems  reflecting 
the  unit  is  to  not  display  an  object  (hidden). 

8.3.5  Representation  of  "Active"  units 

When  the  status  of  a  unit  is  set  as  «  Active  » the  object  shall  be  displayed  in  the  systems  reflecting  the 
unit. 

As  the  same  aggregate  entity  can  simultaneously  exist  in  several  locations,  multiple  representations  have 
to  be  managed  by  the  simulations.  To  ensure  its  membership  to  the  same  units  in  shared  Order  of  Battle, 
simulations  have  to  use  similar  callsign  for  different  representations  of  a  same  unit. 

For  multiple  naming,  see  section  Transport  by  several  transporters  in  several  travels  with  ToC. 

For  multiple  representations,  see  illustration  in  section  Illustration. 

A  unit  single  representation  during  transportation  is  also  possible: 

•  Using  a  non  non-divisible  unit  (no  available  information  on  content,  or  to  small  unit  to  be 
divided), 

•  Using  a  transport  in  one  travel  by  one  single  transporter  (with  or  without  Transfer  of  Control). 

For  a  multiple  represented  unit;  addition  of  its  different  potentials  should  not  exceed  100%  for  a  same 
item. 

8.3.6  Example:  Transport  by  one  single  transporter  in  one  travel  with  ToC 

In  this  case,  the  provider  is  able  to  transport  a  complete  unit  (from  the  consumer)  using  one  single 
transporter  (boat,  aircraft,  train)  and  doing  one  single  trip. 

The  transported  unit  is  deactivated  at  the  embarkment  time  and  reactivated  at  the  disembarkment 
location  at  the  right  time. 

If  the  transporter  is  destroyed,  the  consumer  service  is  cancelled  and  the  transported  unit  is  never 
reactivated. 

8.3.7  Example:  Transport  by  several  transporters  in  several  travels  with  ToC 

In  this  case,  a  transported  unit  transfers  a  list  of  platform  entities  for  each  transporter.  This  seems  to  be 
equivalent  to  a  transfer  of  equipments  for  Supply  pattern.  For  each  embarkment  event,  a  NETN 
aggregate  object  update  is  published  by  the  transported  unit. 

If  there  are  no  more  platform  entities  to  transport,  the  transported  unit  is  deactivated  (aggregate  status 
attribute  to  inactive). 

If  the  transported  unit  is  still  active  (because  embarkment  is  not  completed)  when  a  disembarkment 
occurs,  a  temporary  Bridgehead  unit  is  activated  at  the  disembarkment  location.  It  uses  a  new  HLA  ID 
and  the  same  callsign  than  the  transported  unit,  but  with  an  extension  (-bh). 

For  each  disembarkment  event,  embarked  platform  entities  are  transferred  toward  a  Bridgehead  unit. 

When  the  transported  unit  is  no  longer  active  (transport  service  is  completed),  the  Bridgehead  unit  is 
suppressed  and  the  original  unit  replaces  it  at  the  same  location. 


If  a  transporter  is  destroyed  with  transported  units  onboard,  consumer  service  continues  until  service 
completion  by  other  transporters. 

Only  one  Bridgehead  and  one  Disembarkment  location  per  transported  unit  is  supported. 

8.3.8  Illustration 

The  following  scheme  illustrates  a  transport  by  several  transporters  (boats)  in  several  travels,  with 
Transfer  of  Control  and  multiple  representation  aspect. 
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8.4  Supply  Pattern 

Services  for  resupply  of  consumable  materials  include: 

•  Supply  service  provided  by  a  facility,  a  unit  or  any  battlefield  entity  with  consumable  materials 
supply  capability, 

•  Storage  service  provided  by  a  facility  or  means  of  transportation  capable  of  storing  consumable 
materials. 

These  two  services  are  different  in  terms  of  flow  of  materials  between  service  consumer  and  provider.  In 
the  supply  service,  materials  are  transferred  from  the  service  provider  to  the  service  consumer.  In  the 
storage  service,  the  user  of  the  storage  facility  necessarily  has  material  which  requires  storage,  thus  the 
materials  are  transferred  from  the  service  consumer  (e.g.  a  transport  arriving  at  a  depot)  to  the  service 
provider  (e.g.  the  storage  facility)  using  the  storage  service. 

Both  services  follow  the  basic  NETN  Service  Consumer-Provider  pattern  to  establish  a  service  contract 
and  a  service  delivery. 

Materials  will  be  transferred  after  the  offer  is  accepted  and  the  service  is  started.  This  pattern  allows 
partial  transfers.  This  means  that  only  some  of  the  materials  described  in  the  service  contract  are 
transferred.  If  the  service  is  cancelled  during  service  delivery,  the  provider  must  inform  the  consumer  of 
the  amount  and  type  of  material  transferred. 

If  requested  materials  are  only  partially  transferred  in  the  NETN_ServiceStarted  interaction,  the 
consumer  has  to  start  another  NETN_RequestSupply  in  order  to  obtain  all  desired  supplies. 

8.4.1  Supply  Service 
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NETN_RequestSupply  is  used  by  a  consumer  to  initiate  a  request  for  supply  from  a  supply  service 
provider.  Amount  and  type  of  materials  are  included  in  the  request.  In  this  request,  the  consumer 
specifies  a  preference  for  whether  the  loading  is  done  by  the  provider  or  by  the  consumer. 


NETN_OfferSupply  is  used  by  a  supply  service  provider  to  indicate  which  of  the  requested  materials 
(amount  and  type)  can  be  offered.  In  this  offer  the  provider  can  agree  with  the  consumer's  loading 
request  or  counter-offer  based  on  current  loading  capability. 

NETN_ReadyToReceiveSupply  is  used  by  a  service  consumer  to  indicate  that  supply  delivery  may  start.  It 
also  updates  the  requested  amount  of  supplies  based  on  the  consumer's  current  supply  requirements  at 
the  time  the  consumer  is  ready  to  receive  supplies.  Note  that  the  updated  supply  amount(s)  are  subject 
to  the  constraint  that  the  amount(s),  by  type,  must  be  less  than  or  equal  to  the  amount(s),  by  type,  of 
offered  supplies. 

NETN_SupplyComplete  is  used  by  the  service  provider  to  inform  the  consumer  of  the  amount,  by  type, 
of  supplies  transferred.  This  allows  for  supply  pattern  interruptions  due  to  operational  necessity, 
death/destruction  of  either  the  consumer  or  provider  during  resupply,  etc. 

Transfer  of  materials  in  supply  service  is  considered  as  complete  when: 

•  The  service  consumer  receives  a  NETN_SupplyComplete  interaction  and 

•  The  service  provider  receives  a  NETN_ServiceReceived  interaction. 

If  the  time  specified  in  the  RequestTimeOut  parameter  of  the  NETN_RequestSupply  passes  without  the 
Provider  sending  a  NETN_OfferSupply,  the  Consumer  shall  send  a  NETN_CancelService.  The  Consumer 
may  then  again  initiate  a  NETN_RequestSupply  interaction. 

The  LoadingDoneByProvider  parameter  is  used  by  the  consumer  to  propose  whether  the  loading  is  done 
by  him  or  by  equipment  belonging  to  the  facility;  the  provider  can  agree  or  disagree  with  the  consumer's 
proposal. 

When  ready  to  receive,  the  consumer  can  indicate  a  modified  SuppliesData  to  include  fewer/less 
supplies  than  offered  by  the  provider.  Note  that  NETN_ReadyToReceiveSupplies. SuppliesData  must  be 
less  than  or  equal  to  the  NETN_OfferSupply. SuppliesData  amount. 

The  provider  can  transfer  only  a  part  of  the  offered  materials  (partial  transfer);  the  actual  transferred 
supplies  are  identified  in  SuppliesData  parameter  of  the  NETN_SupplyComplete  interaction. 

The  consuming  entity  shall  issue  a  NETN_ServiceReceived  in  response  to  the  NETN_SupplyComplete 
interaction.  Transfer  of  supplies  is  considered  as  complete  once  the  NETN_ServiceReceived  is  issued. 

Early  termination  of  the  service  request  or  delivery  (as  defined  in  the  Service  Consumer-Provider 
Pattern)  is  possible  by  either  consumer  or  provider  initiating  a  NETN_CancelService.  If  the 
NETN_CancelService  occurs  between  NETN_ServiceStarted  and  NETN_SupplyComplete,  the  provider  will 
inform  the  consumer  of  the  amount  of  supplies  transferred  using  NETN_SupplyComplete. SuppliesData. 


Rejection  of  a  service  offer  is  allowed.  In  this  case,  no  material  will  be  transferred. 


8.4.2  Storage  Service 
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NETN_RequestStorage  is  used  by  a  consumer  to  initiate  a  request  for  storage  of  supplies.  Amount  and 
type  of  materials  are  included  in  the  request. 

NETN_OfferStorage  is  used  by  a  storage  service  provider  to  indicate  which  (amount  and  type)  of  the 
requested  materials  can  be  stored. 

NETN_StorageStarted  is  used  by  a  service  provider  to  indicate  that  the  (partial)  storage  of  requested 
materials  has  started. 

The  consuming  entity  shall  issue  a  NETN_ServiceReceived  as  response  to  the  NETN_ServiceCompleted 
interaction.  Transfer  of  supplies  is  considered  as  complete  once  the  NETN_ServiceReceived  is  issued. 

The  consumer  determines  whether  the  loading  is  done  by  him  or  by  equipments  belonging  to  the  facility. 

The  storage  provider  can  limit  the  transfer  of  supplies  to  a  subset  of  the  offered  supplies  when  issuing 
the  NETN_StorageStarted  interaction. 

Early  termination  of  the  service  request  or  delivery  (as  defined  in  the  Service  Consumer-Provider 
Pattern)  is  possible.  On  early  termination,  no  materials  will  be  transferred. 

Rejection  of  a  service  offer  is  allowed.  In  this  case,  no  materials  will  be  transferred. 

8.5  Maintenance  Pattern 
8.5.1  Repair  Service 

Repair  service  can  be  performed  on  equipments  (i.e.  non-consumables  items  such  as  platforms). 
Providers  of  this  service  are  facilities  capable  of  performing  requested  repairs. 

The  service  is  initiated  by  a  NETN_RequestRepair  interaction,  sent  by  a  federate  modelling  the  owner  of 
damaged  equipments  (for  example  damaged  platforms).  The  service-provider  offer  the  repair  service  by 
sending  the  NETN_OfferRepair  interaction.The  NETN  Service  Consumer-Provider  interactions  are  used  to 
complete  the  service. 


Note:  The  maintenance  pattern  does  not  include  a  transfer  of  control  of  the  damaged  platform  to 
the  repairing  facility.  If  such  a  transfer  was  reguired,  the  consumer  should  initiate  a  reguest  for 
deposit  (instead  of  reguest  for  repair)  with  an  attached  work  order  describing  the  reguired 
repairs. 
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The  RepairData  parameter  is  a  list  of  equipments  and  type  of  repairs.  List  of  offered  repairs  may  be 
different  from  the  list  of  requested  repairs.  If  the  HLA  object  (equipment  to  be  repaired)  has  a  damaged 
state,  the  list  of  requested  repairs  could  be  empty. 

The  provider  federate  models  the  efforts  to  repair  a  damaged  platform. 

If  the  consuming  entity  is  an  aggregate  entity,  its  damaged  equipment  has  to  be  listed  in  a  platform  list 
to  get  repaired. 

8.5.2  Repair  Types 

The  RepairTypeEnuml6  enumerated  data  type  is  defined  in  the  RPR-FOM  v2.0  and  identifies  a  large  set 
of  repair  types.  DIS  does  not  define  the  enumerated  values  as  part  of  the  core  specification.  Enumerated 
values  are  defined  in  a  separate  agreements  document  instead. 

In  the  RPR-FOM  however  values  are  defined  as  a  fixed  part  of  some  enumerated  data  types.  In  order  not 
to  violate  the  modular  FOM  merging  rules,  the  NETN  Logistics  FOM  module  does  not  define  any 
extensions  to  these  data  types  as  part  of  the  FOM  module.  A  separate  table  for  adding  values  to  the 
existing  range  of  enumerations  defined  in  the  RPR-FOM  is  allowed  instead. 

This  table  shall  be  part  of  any  federation  specific  agreements  where  extensions  to  an  enumerated  data 
type  are  required.  It  is  also  recommended  but  not  required  that  any  additional  enumerated  values  added 
to  this  data  type  shall  be  submitted  as  Change  Requests  to  the  SISO  RPR-FOM  Product  Development 
Group.  All  existing  enumerators  in  RPR-FOMv2.0  and  their  values  are  reserved.  Additional  repair  types 
are  documented  in  the  federation  specific  agreements. 


8. 6  Convoy  Pattern 

Convoy  services  are  used  in  any  cases  covering  management  or  transport  of  non-consumable  materials 
such  as  platforms,  units  or  battlefield  entities. 

Services  for  Convoy  include: 

•  Transport  service  provided  by  a  means  of  transportation  capable  of  storing  and  delivering  non¬ 
consumable  materials. 

•  Embarkment  service  provided  by  a  means  of  transportation  capable  of  storing  non-consumable 
materials. 

•  Disembarkment  service  provided  by  a  means  of  transportation  capable  of  delivering  non¬ 
consumable  materials. 

Both  Embarkment  and  Disembarkment  services  could  also  be  extended  to  management  of  facilities;  with 
the  capability  of  delivering  and  storing  non-consumable  materials  to/from  other  facilities,  units  or 
battlefield  entities. 

Convoy  services  include  a  "Transfer  of  Control"  mechanism  between  a  service  consumer  and  a  service 
provider  over  the  unit  managed  by  the  means  of  transportation  (see  section  Transfer  of  Control). 

Convoy  services  differ  in  terms  of  the  flow  of  units  between  service  consumer  and  service  provider: 

•  In  Disembarkment  service,  units  are  transferred  from  a  service  provider  to  a  service  consumer. 

•  In  Embarkment  service,  units  are  transferred  from  a  service  consumer  to  a  service  provider. 

•  In  Transport  service,  both  types  of  units  transfer  (generated  by  Embarkment  and  Disembarkment 
services)  exist. 

All  convoy  services  follow  the  basic  NETN  Service  Consumer-Provider  pattern  for  establishing  a  service 
contract  and  a  service  delivery.  The  following  interaction  classes  are  extensions  of  the  NETN  Service 
Consumer-Provider  interactions: 

•  NETN_RequestConvoy  interaction  is  used  by  a  consumer  to  initiate  a  request  of  convoy  to  a 
convoy  service  provider.  Convoyed  units  and  constraints  are  included  in  the  request. 

•  NETN_OfferConvoy  interaction  is  used  by  a  convoy  service  provider  to  indicate  which  of  the 
requested  units  can  be  managed.  In  this  offer,  a  provider  can  change  the  constraints  specified  in 
the  request  and  propose  to  manage  only  a  part  of  asked  units. 

•  NETN_RejectOfferConvoy  interaction  is  used  by  a  service  consumer  to  signify  his  disagreement 
to  the  provider  about  the  proposal.  Consumer  can  indicate  the  reason  of  his  reject. 

•  NETN_CancelConvoy  interaction  is  used  by  a  service  consumer  or  a  service  provider  to  cancel 
the  negotiated  convoy  service.  The  reason  of  the  cancel  can  be  indicated. 

During  Convoy  services  execution,  a  service  provider  can  inform  a  service  consumer  about  the  service 
progress  using  the  following  interactions: 

•  NETN_ConvoyEmbarkmentStatus  interaction  is  used  by  a  service  provider  to  indicate  precisely 
when  units  are  embarked,  so  when  ToC  is  applied. 

•  NETN_ConvoyDisembarkmentStatus  interaction  is  used  by  a  service  provider  to  indicate 
precisely  when  units  are  disembarked,  so  when  ToC  is  restored. 

•  NETN_ConvoyDestroyedEntities  interaction  is  used  by  a  service  provider  to  indicate  the  damage 
state  of  unit  during  the  ToC. 


The  following  NETN  Service  Consumer-Provider  interactions  are  also  used  in  Convoy  pattern: 


•  NETN_AcceptOffer 

•  NETN_ReadyToReceiveService 

•  NETN_ServiceStarted 

•  NETN_ServiceComplete 

•  N  ETN_ServiceReceived 

8.6.1  Transport  service 


Consumer 


Provider 


N  ETN_Req  uestCon voy  (tra  nsport Data ) 

- ► 

NETN_OfferConvoy  (transportData,  listOfTransporter) 

◄ - 

N ETN_Accept Offer  /  RejectOfferConvoy  (reason) 

- ► 

NETN_ReadyToReceiveService 

- ► 


N  ETN_ServiceSta  rted 

◄ - 


NETN_ConvoyEmbarkmentStatus  (listObjectEmbarked,  transportID)  ^ 

Q 

Transfer  of 
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*  <? 

NETN_ConvoyDisembarkmentStatus  (listObjectDisembarked,  transportID)  ^ 

>- 

* 

- ' 

NETN_ServiceComplete 


◄ - 

NETN_ServiceReceived 

- ► 

A  Consumer  makes  a  request  for  transport  with  the  following  data: 

•  Time  and  location  where  units  would  like  to  embark  and  disembark, 

•  Characteristics  of  each  simulated  entity  to  manage, 

A  Provider  offers  a  response  to  the  consumer  with  the  following  parameters: 

•  Time  and  location  where  units  could  embark  and  disembark, 

•  List  of  simulated  entities  the  Provider  is  able  to  manage  and  transport  units  planned  to  be  used, 

Offered  services  are  accepted  only  when  both  service  Consumer  and  Provider  are  agreeing  about  the 
conditions  for  delivery  the  service.  Provider  can  change  some  elements  of  the  request  in  this  offer: 

•  Time  and  location  where  units  must  be  embarked  and  disembarked,  if  the  requirements  of  the 
request  cannot  be  satisfied. 

•  Partial  delivery  offer  by  managing  fewer  units  than  requested. 

To  achieve  Transport  service,  Consumer  must  be  present  on  time  at  the  meeting  point  in  order  to 
embark  and  publish  the  NETN_ReadyToReceiveService  interaction. 

During  a  Transport  service  execution,  each  transporter  enters  a  loop  where: 


•  It  publishes  a  list  of  embarked  units.  The  responsibility  of  units  specified  in  this  list  is  transferred 
to  the  Provider  until  disembarkment  (see  section  Transfer  of  Control) 

•  It  publishes  a  list  of  disembarked  entities.  The  responsibility  of  entities  specified  in  this  list  is 
restored  to  the  Consumer  when  disembarked  (see  section  Transfer  of  Control) 

Both  NETN_ConvoyEmbarkmentStatus  and  NETN_ConvoyDisembarkmentStatus  interactions  can  be 
repeated  as  much  as  needed,  if  transportation  needs  to  be  realized  in  several  iterations. 

A  Transport  service  is  considered  as  closed: 

•  When  service  Provider  receives  a  NETN_ServiceReceived  interaction  and  service  Consumer 
receives  a  NETN_ServiceCompleted  interaction. 

•  Or  when  a  NETN_CancelConvoy  or  a  NETN_RejectOfferConvoy  is  used  by  the  service  Provider  or 
Consumer. 

If  a  Transport  service  is  cancelled: 

•  During  a  delivery  phase  (between  start  and  complete): 

o  All  units  already  embarked  or  partially  embarked  are  kept  by  the  service  Provider.  A  new 
Request  is  needed  by  the  service  Provider  to  continue  to  embark  or  disembark  units 
(restore). 

o  All  units  already  disembarked  or  partially  disembarked  are  kept  by  the  service 

Consumer.  A  new  Request  is  needed  by  the  service  Provider  to  continue  to  disembark  or 
re-embark  units  (restore). 

•  During  a  negotiation  phase  (before  start):  transaction  between  service  Consumer  and  Provider  is 
considered  as  closed  without  delivery  of  service. 

•  After  a  service  delivery  (after  complete):  a  cancel  does  not  make  sense  in  this  case  (no  effect). 

8.6,2  Embarkment  service 

Consumer  Provider 

NETN_RequestConvoy  (transportData) 


NETN_OfferConvoy  (transportData,  MstOfTransporter) 

◄ - 

NETN_AcceptOffer  /  RejectOfferConvoy  (reason) 
NETN_ReadyToReceiveService 
N  ETN_Se  rvi  ceSta  rt  ed 

◄ - 

NETN_ConvoyEmbarkmentStatus  (listObjectEmbarked,  transportID) 

◄ - 

NETN_ServiceComplete 

◄ - 

NETN  ServiceReceived 


Transfer 
of  control 


A  Consumer  makes  a  request  for  embarkment  with  the  following  parameters: 

•  Time  and  location  where  units  would  like  to  embark, 

•  Characteristics  of  each  simulated  entity  to  manage, 


A  Provider  offers  a  response  to  the  Consumer  with  the  following  parameters: 


•  Time  and  location  where  units  could  embark, 

•  List  of  simulated  entities  the  Provider  is  able  to  manage  and  transport  units  planned  to  be  used, 

Offered  services  are  accepted  only  when  both  service  Consumer  and  Provider  are  agreeing  about  the 
conditions  for  delivery  the  service.  Provider  can  change  some  elements  of  the  request  in  this  offer: 

•  Time  and  location  where  units  must  be  embarked,  if  the  requirements  of  the  request  cannot  be 
satisfied. 

•  Partial  delivery  offer  by  managing  fewer  units  than  requested. 

To  achieve  Embarkment  service,  Consumer  must  be  present  on  time  at  the  meeting  point  in  order  to 
embark  and  publish  the  NETN_ReadyToReceiveService  interaction. 

During  an  Embarkment  service  execution,  each  transporter  enters  a  loop  publishing  a  list  of  embarked 
units.  The  responsibility  of  units  specified  in  this  list  is  transferred  to  the  Provider  and  never  given  back 
to  the  Consumer  in  this  protocol  (see  section  Transfer  of  Control). 

A  NETN_ConvoyEmbarkmentStatus  interaction  can  be  repeated  as  much  as  needed,  if  embarkment 
needs  to  be  realized  in  several  iterations. 

An  Embarkment  service  is  considered  as  closed: 

•  When  service  Provider  receives  a  NETN_ServiceReceived  interaction  and  service  Consumer 
receives  a  NETN_ServiceCompleted  interaction. 

•  Or  when  a  NETN_CancelConvoy  or  a  NETN_RejectOfferConvoy  is  used  by  the  service  Provider  or 
Consumer. 

If  an  Embarkment  service  is  cancelled: 

•  During  a  delivery  phase  (between  start  and  complete):  all  units  already  embarked  or  partially 
embarked  are  kept  by  the  service  Provider.  The  status  of  this  units  stay  as  Inactive.  A  new 
Request  is  needed  by  the  service  Provider  to  continue  to  embark  or  disembark  units  (restore). 

•  During  a  negotiation  phase  (before  start):  transaction  between  service  Consumer  and  Provider  is 
considered  as  closed  without  delivery  of  service. 

•  After  a  service  delivery  (after  complete):  a  cancel  does  not  make  sense  in  this  case  (no  effect). 


8.6,3  Disembarkment  service 


Consumer 


Provider 


NETN_RequestConvoy  (transportData) 

- ► 

NETN_OfferConvoy  (transportData,  listOfTransporter) 

◄ - 


N ETN_Accept Offer  /  RejectOfferConvoy  (reason) 


NETN_ReadyToReceiveService 


N  ETN_ServiceSta  rted 

◄ - 

NETN_ConvoyDisembarkmentStatus  (listObjectDisembarked,  transportID) 

◄ - 

NETN_ServiceComplete 

◄ - 
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NETN_ServiceReceived 
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A  Consumer  makes  a  request  for  disembarkment  with  the  following  parameters: 

•  Time  and  location  where  units  would  like  to  disembark, 

•  Characteristics  of  each  simulated  entity  to  manage, 


A  Provider  offers  a  response  to  the  Consumer  with  the  following  parameters: 

•  Time  and  location  where  units  could  disembark, 

•  List  of  simulated  entities  the  Provider  is  able  to  manage  and  transport  units  planned  to  be  used, 

Offered  services  are  accepted  only  when  both  service  Consumer  and  Provider  are  agreeing  about  the 
conditions  for  delivery  the  service.  Provider  can  change  some  elements  of  the  request  in  this  offer: 

•  Time  and  location  where  units  must  be  disembarked,  if  the  requirements  of  the  request  cannot 
be  satisfied. 

•  Partial  delivery  offer  by  managing  fewer  units  than  requested 

To  achieve  Disembarkment  service,  Consumer  must  publish  the  NETN_ReadyToReceiveService 
interaction. 

During  a  Disembarkment  service  execution,  each  transporter  enters  a  loop  where  it  publishes  a  list  of 
disembarked  entities.  The  responsibility  of  entities  specified  in  this  list  is  restored  to  the  Consumer  when 
disembarked  (see  section  Transfer  of  Control). 

A  NETN_ConvoyDisembarkmentStatus  interaction  can  be  repeated  as  much  as  needed,  if  embarkment 
needs  to  be  realized  in  several  iterations. 


A  Disembarkment  service  is  considered  as  closed: 


•  When  service  Provider  receives  a  NETN_ServiceReceived  interaction  and  service  Consumer 
receives  a  NETN_ServiceCompleted  interaction. 

•  Or  when  a  NETN_CancelConvoy  or  a  NETN_RejectOfferConvoy  is  used  by  the  service  Provider  or 
Consumer. 

If  a  Disembarkment  service  is  cancelled: 

•  During  a  delivery  phase  (between  start  and  complete):  all  units  already  disembarked  or  partially 
disembarked  are  kept  by  the  service  Consumer.  A  new  Request  is  needed  by  the  service  Provider 
to  continue  to  disembark  or  re-embark  units  (restore). 

•  During  a  negotiation  phase  (before  start):  transaction  between  service  Consumer  and  Provider  is 
considered  as  closed  without  delivery  of  service. 

•  After  a  service  delivery  (after  complete):  a  cancel  does  not  make  sense  in  this  case  (no  effect). 
Variations: 

•  Disembarkment  protocol  can  start  with  a  Consumer  interaction  as  well  as  with  a  Provider  one.  If 
a  Provider  initiates  a  Disembarkment  (planned  operation),  the  protocol  execution  starts  directly 
at  the  second  step  (NETN_OfferConvoy),  without  processing  the  query  phase 
(NETN_RequestConvoy). 

Exception:  see  section  Scenario  Preparation  Phase. 

In  case  of  "scenario  preparation  phase",  Disembarkment  pattern  could  be  affect.  The  case  is  detail  at  the 
end  of  this  document. 

8.6.4  Convoy  Services  and  Attrition 

During  the  execution  of  a  Convoy  service  transporter  may  be  engaged  by  other  units  or  otherwise 
affected  by  the  simulated  environment.  This  attrition  can  affect  the  delivery  of  the  service  and  requires 
additional  interactions  to  notify  service  consumers  about  any  lost/destroyed  entities. 


Consumer 


Provider 


Federation 


Munition  detonation  on  transporter 


Compute  Damage 


NETN_ConvoyDestroyedEntities  (ListOfEmbarkedObjectDestroyed) 

4 - 


Update  of 


destroyed  Objects 


A  Convoy  service  Provider  can  use  a  NETN_ConvoyDestroyedEntities  interaction  to  define  transported 
units  destroyed  during  the  service  execution  and  inform  the  Consumer. 


For  example,  if  a  transporter  is  destroyed  with  transported  units  on  board,  transported  entities  are  also 
destroyed.  Therefore,  whenever  a  convoy  service  provider  receives  interactions  (e.g. 


MunitionDetonation)  attrition  on  embarked  entities  is  calculated.  The  Convoy  service  Provider  then 
sends  a  list  of  destroyed  objects  to  the  service  consumer.  The  Convoy  service  consumer  can  use  this  list 
to  update  its  situation  or  to  cancel  transaction  in  progress. 

The  NETN_ConvoyDestroyedEntities  interaction  can  take  place  at  anytime  between  the  start  of  the 
service  (ServiceStarted  interaction)  and  the  end  of  the  service  (ServiceComplete  interaction). 

Impact  on  the  Convoy  service  Pattern  could  be  the  following: 

Ex:  Vessel  «  1  »  and  «  2  »  must  be  transporters.  Some  units  need  to  be  transported  in  two  rotations  on 
each  Vessel.  We  study  the  case  where  Vessel  «  1  »  is  destroyed  during  its  first  rotation  and  Vessel  «  2  » 
destroyed  during  its  second  rotation: 


Stage 

Interactions 

Negotiation  phase  and  start  of  the 
service 

First  rotation:Vessel  1  and  Vessel  2 

embark  units 

Provider  send: 

NETN_ConvoyEmbarkmentStatus  (listl,  Vessell) 

NETN ConvoyEmbarkmentStatus  (Iist2,  Vessel2) 

During  transport,  service  Provider 
received  MunitionDetonation 

Vessel  1  is  destroyed 

Provider  send: 

NETN_Convoy  Destroyed  Entities  (listl) 

Vessel  2  disembark  his  units 

Provider  send: 

NETN ConvoyDisembarkmentStatus  (Iist2,  Vessel2) 

Second  rotation:  Vessel  2  embark  units 

Provider  send: 

NETN ConvoyEmbarkmentStatus  (Iist3,  Vessel2) 

During  transport,  service  Provider 
received  MunitionDetonation 

Vessel  2  is  destroyed 

Provider  send: 

NETN_Convoy  Destroyed  Entities  (Iist3) 

End  of  service  or  Cancel 

We  notice  that  a  NETN_ConvoyEmbarkmentStatus  interaction  does  not  necessarily  fit  a 

NETN_ConvoyDisembarkmentStatus  interaction. 

8.6.5  Convoy  datatypes 

To  be  able  to  manage  different  levels  of  granularity  between  simulators,  a  definition  of  the  object  to 
convoy  is  encapsulated  in  a  temporary  structure. 

To  make  a  Convoy,  federate  shall  build  a  list  of  elements  and  exchange  it  to  negotiate  the  service. 

The  figure  below  shows  the  content  of  such  a  list  and  how  elements  for  Convoy  service  are  defined 
towards  NETN_ArrayOfObjectDefinition. 


INETN_ArrayOfObjectDefinition 

Struct 

An  HLAVariableArray  that 
contains  detail  on  platform 
to  embark. 

^  GbjectDefinitionList  :  List<NETN_ObjectDefinition5truct> 


EntityFeatureStruct  is  a  HLAVariantRecord, 

The  enumerator  defines  which  kind  of  data  are  present  for  the 
detail  : 

NoDetailj  there  no  additional  data. 

EntityDetail_Other,  the  ObjectDetail  field  shall  be  present. 
EntityDetailJ-iuman^  the  HumanDetail  field  shall  be  present. 
EntityDetail_Equipementj  the  EquipDetail  field  shall  be  present. 
EntityDetaiLPlatfornri;  the  PlatformDetail  field  shall  be  present. 
AggregateDetailj  SubObjectList  shall  be  present. 
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EquipDetail  :  EquipDescription 
#  FeatureLevel  :  NETN_FeatureLevelEnum 
HumanDetail  :  HumanDescription 
^  ObjectDetail  :  NETN_ObjectDefinition 
PlatformDetail  :  NETN_PlatformDescription 
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!=§*  Damage5tate  :  Damage5tatusEnum32 
EquipType  :  EntityTypeStruct 
^  Quantity  :  int 


HumanDescription 

Struct 
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□  Proprietes 

]§*  HumanType  :  EntityTypeStruct 
Injury  :  InjuryTypeEnumS 
Quantity  :  short 


NETN_ObjectDefinitiont 
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S'  Type  :  HLAA5CII5tring 
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NETN_PlatformDescription 

Struct 

□  Proprietes 

*  DamageState  :  Damage5tatusEnum32 
r  PlatformType  :  EntityTypeStruct 


Interactions  use  NETN_AppointmentStruct  to  define  date,  time  and  location  of  desired  Convoy  service. 
Both  Consumer  and  Provider  must  agree  on  these  data  to  accept  the  service. 


NETN_AppointmentStruct 

Struct 


□  Proprieties 


DateTime  :  HLAUnsigned64BE 
Location  :  WorldLocationStruct 


8.6.6  Scenario  preparation  phase 

A  scenario  preparation  phase  entails  to  share  information  (online  or  offline)  between  simulations. 
Therefore,  a  strategy  is  needed  before  running  an  experimentation  to  share  data  (scenario,  units  types 
(EntityType),  callsign,  etc.). 


Concerning  Disembarkment  service,  a  scenario  can  start  to  run  with  already  embarked  units.  The 
embarkment  phase  is  supposed  to  have  taken  place  during  the  scenario  preparation  phase,  so 
simulations  do  not  have  to  play  it  using  interactions. 

To  allow  simulations  to  play  such  cases,  we  propose  the  following  solution: 

•  For  Embarkment,  in  preparation  phase  of  a  simulation,  the  EmbeddedllnitList  allows  to  describe 
on  board  elements.  This  list  contains  items  (like  callsigns)  provided  by  simulations  that  want  to 
see  them  embarked  at  scenario  start. 

•  The  synchronization  process  for  two  simulations  in  a  scenario  preparation  phase  (offline)  is  the 
following: 

o  Simulation  A  (Consumer)  provides  information  (offline)  to  simulation  B  (Provider)  on 
elements  that  must  be  on  board  at  the  beginning  of  scenario  execution  (Callsigns, 
scenario  elements), 

o  Simulation  B  initializes  its  scenario  with  these  elements, 

o  During  scenario  execution,  Simulation  B  publishes  information  on  embarked  elements 
using  «  EmbeddedllnitList  », 

o  During  the  first  HLA  objects  discover,  Simulation  A  analyzes  «  EmbeddedllnitList  » 
attributes,  looking  for  its  own  potentially  embarked  elements, 
o  Simulation  A  updates  its  embarked  elements  (inactivation), 
o  Simulations  A  &  B  use  interactions  as  defined  in  Disembarkment  protocol. 

•  This  procedure  allows  limiting  synchronization  and  data  capture  errors  between  simulations 
during  preparation  phase. 

8.6.7  Convoy  Pattern  Exception 

Two  ways  are  possible  in  order  to  disembark  units: 

•  A  service  Provider  waits  for  a  request  service  for  disembarkment  of  embarked  units  (see 
standard  Disembarkment  protocol). 

•  A  service  Provider  sends  directly  a  NETN_ServiceStarted  to  the  Consumer  (see  schema  below). 

This  second  way  bypasses  the  regular  negotiation  phase  (see  standard  Disembarkment  protocol).  It  could 
be  employed  to  disembark  already  embarked  units  at  scenario  beginning. 
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8. 7  RPR-FOM  Platform  Objects  Class  Extensions 

Platforms  are  a  central  element  in  the  Logistics  FOM  through  which  units  can  be  transported.  In  the 
Logistics  FOM  Module  the  RPR-FOM  platform  object  classes  are  subclasses  to  add  additional  information 
used  in  the  Logistics  pattern  described  in  this  document. 

We  chose  to  add  attributes  to  «RPR  Platform  object»  children  to  define  Current  state  of  Embarked 
elements  on  transporter  platforms.  Indeed,  interactions  have  a  limited  lifetime  and  do  not  allow  to 
update  a  state  at  any  time  on  the  HLA  federation. 

EmbeddedUnitList  provides  the  list  of  elements  carried  by  a  transporter.  Listed  items  are  composed  of  « 
Callsigns  »  of  on-board  units  (aggregates  or  platforms).  The  list  is  updated  by  the  transporter  according 
to  carried  elements. 

8.8  Facility  object  class 

Facilities  are  a  central  element  in  the  Logistics  FOM  through  which  material  can  be  transferred. 

Facilities  could  be  created  during  a  simulation  or  be  a  part  of  the  infrastructure  (railway  station,  storage 
tanks  depot,  port,  etc.).  A  facility  could  also  be  part  of  a  unit  (ship,  etc.). 

The  RPR-FOM  v2.0  BaseEntity  object  class  is  extended  with  a  subclass  NETN_Facility,  with  the  following 
attributes  (inherited  parameters  are  written  in  italics): 


|  HLAobjectRoot. BaseEntity. NETN Facility 

Attribute  Name 

Datatype 

Default 

Value 

Definition 

Usage 

Entityldentifier 

Entity  IdentifierStruct 

Not 

Optional 

Identifies  the  site ,  application , 
and  entity  number  of  this 
object  instance.  It  is  used  for 
group  addressing  in  the  SIMAN 
interactions. 

Reguired 

EntityType 

EntityTypeStruct 

Not 

Optional 

Kind ,  Country ,  Domain , 

Category ,  Subcategory , 

Specific ,  and  Extra  fields  of  the 
DIS  Entity  Type. 

Reguired 

IsPartOf 

IsPartOfStruct 

All  zeros 

Used  to  indicate  that  there  is  a 
spatial  relationship  between 
this  entity  and  a  host  entity, 
i.e.,  one  entity  is  "part  of" 
another 

Optional 

for 

NETN_Facil 

ity 

RelativeSpatial 

SpatialStruct 

All  zeros 

Used  to  express  the  spatial 
relationship  between  the 
entity  and  a  host  entity.  Used 
in  addition  to  the  normal 
spatial  attribute  which 
describes  absolute  location. 

Optional 

for 

NETN_Facil 

ity 

Spatial 

SpatialStruct 

Not 

Optional 

Used  to  express  the  spatial 
relationship  between  the 
entity  and  the  center  of  the 
Earth. 

Required 

DamageState 

DamageStatusEnum3 

2 

No  Damage 

Damage  State  of  Facility 

Required 

for 

NETN_Facili 

ty 

Attribute  Name 


Datatype 


Default 

Value 


Definition 


Usage 


Forceldentifier 

ForceldentifierEnum8 

Other 

Enumeration  distinguishing 
the  different  teams  or  sides  in 

an  exercise. 

Required 

for 

NETN_Facili 

ty 

Callsign 

NETN_Callsign 

Not 

Optional 

Callsign  of  the  facility. 

Required 

UniquelD 

NETNJJniquelD 

Unique  id  of  the  facility 
instance. 

IsOperational 

HLAboolean 

HLAtrue 

True  if  the  facility  is 
operational  and  can  provide 
service 

StorageList 

SupplyArray 

Not 

Optional 

List  of  Materials  (Amount, 

Type)  stored  in  the  facility  (no 
platforms).  Material  loaded  on 
means  or  on  resources  of 
transport  which  are  located  in 
the  facility  are  also  included. 
Material  belonging  to  an 
object  of  the  object  list  is 
excluded. 

Required 

PlatformList 

UniqueldArrayStruct 

Not 

Optional 

List  of  non-active 
platforms/units  in  the  facility. 
Includes  those  platforms 
transferred  to  the  facility  with 
a  ServiceRequest  (Type  = 
Deposit)  or  located  by  the 
provider-model  in  the  facility. 

Required 

The  specific  type  of  facility  (Service  Type)  is  defined  as  part  of  the  EntityType  attribute.  The  following 
enumeration  scheme  is  to  be  used  for  the  following  service  types. 


Type  of  Facility 

Kind. Dom.Cou.Cat.Sub. Spec. Ex  (EntityType) 

Storage  (Material) 

TBD 

Maintenance 

TBD 

Medical 

TBD 

FARP 

TBD 

TBD  Base 

TBD 

NBC 

TBD 

Camp 

TBD 

Enumerations  to  be  definied  in  federation  specific  agreements 


8.9  Interaction  Classes 

The  NETN  Logistics  FOM  module  can  be  used  to  represent  services  for  Supply,  Storage,  Repair,  Transport, 
Embarkment  and  Disembarkment. 

The  basic  pattern  used  by  all  NETN  services  is  the  Service  Consumer-Provider  Pattern  which  defines 
negotiation  and  delivery  of  services. 

Logistics  services  use  interactions  from  this  Service  Consumer-Provider  Pattern  and  extend  them  (if 
needed)  to  support  specific  types  of  logistic  services. 

The  following  Logistics  interactions  class  extensions  to  the  Service  Consumer-Provider  pattern  are  used 
in  the  NETN  Logistics  FOM  Module: 


Class  1 

Class  2 

Class  3 

NETN_Service 

NETN_RequestService 

NETN RequestSupply 

NETN RequestStorage 

NETN RequestRepair 

NETN RequestConvoy 

NETN_  OfferService 

NETN OfferSupply 

N  ETN Off  e  r  Re  pa  i  r 

N  ETN Offe  rStorage 

NETN OfferConvoy 

NETN AcceptOffer 

NETN  Reject  Offer 

NETN RejectOfferConvoy 

NETN ReodyToReceiveService 

NETN ReadyToReceiveSupply 

NETN_ServiceStarted 

N  ETN_StorageSta  rted 

NETN ServiceComplete 

NETN SupplyComplete 

NETN ServiceReceived 

NETN ConcelService 

N  ETN Ca  ncelConvoy 

NETN ConvoyEmbarkmentStatus 

NETN ConvoyDisembarkmentStatus 

NETN ConvoyDestroyedEntities 

8.9,1  NETN_RequestConvoy 

A  request  for  Transport,  Embarkment  or  Disembarkment  of  a  platform  is  initiated  by  a 
NETN_RequestConvoy  interaction  with  the  following  parameters  (inherited  parameters  written  in 
italics): 


|  HLAinteractionRoot.NETN Service.NETN RequestService.NETN RequestConvoy 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN  E  ven  tlden  tifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Convoy  =  3 

RequestTimeOut 

HLAinteger64BE 

Optional 

Defined  a  deadline  (date)  for  the  provider 
response.  Number  of  second  since 
01/01/1970 

TransportData 

N  ETN_T  ra  nsportStruct 

Elements  to 

convoy 

Defined  the  type  of  service  which  will  be 
done;  transport,  embarkment  or 
disembarkment.  The  elements  and 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

constraint  defined  is  function  of  the 

service  to  achieve 

8.9,2  NETN_OfferConvoy 

A  NETN_OfferConvoy  interaction  shall  be  sent  by  the  service  providing  federate  in  response  to  a 
NETN_RequestConvoy  interaction  (inherited  parameters  written  in  italics): 


|  HLAinteractionRoot.NETN Service.NETN OfferService.NETN OfferConvoy 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN E  ven  tlden  tifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Convoy  =  3 

IsOffering 

HLAboolecm 

Not  Optional 

Defines  if  the  requested  service  is 
offered  (=true)  or  not  (=false) 

RequestTimeOut 

HLAinteger64BE 

Optional 

Defined  a  deadline  (date)  for  the 
provider  response.  Number  of  second 
since  01/01/1970 

OfferType 

NETN_OfferTypeEnum32 

Not  Optional 

Provide  high  level  information  about 
the  acceptance  of  the  request 
(Partial,  Full)  without  need  to 
compare  information  from  the  initial 
request  and  the  offer. 

TransportData 

NETN_TransportStruct 

Elements  to 

convoy 

offered  if 
isOffering  = 
true 

Could  be 

contained  less 

elements  than 
the  request 

Defined  the  service  which  will  be 
done  for  transport,  embarkment  or 
disembarkment. 

ListOfTransporters 

NETN_ArrayOfObjectDefi 

nition 

Optional 
(Default: 
empty  list) 

Informative  -  Platform  list  of 
transporters  keep  for  the  service 
(Callsign) 

If  needed,  the  TransportData  parameter  is  allowed  to  be  different  from  the  corresponding  information  in 
the  NETN_RequestConvoy  depending  on  the  constraint  of  service  request.  The  list  of  elements  offered 
by  the  service  provider  can  therefore  be  either  complete  or  partial  (subset)  of  the  elements  requested. 
Constraints  (time  and  location)  can  also  be  different  from  the  request.  If  a  Provider  agrees  with  a 
TransportData  request,  it  repeats  the  data  provided  by  the  Consumer  without  modification. 

8.9.3  NETN_CancelConvoy 

A  NETN_CancelConvoy  interaction  shall  be  sent  by  the  service  providing  or  the  service  Consumer 
federate  to  cancel  the  service  transaction  (inherited  parameters  written  in  italics): 


Full  Name 

HLAinteractionRoot.NETN Service.NETN CancelService.NETN CancelConvoy 

Parameter 

Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

Parameter 

Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN Eventldentifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Convoy  =  3 

Reason 

HLAASCIIstring 

Optional 
(Default:  empty 
String) 

Allows  to  inform  about  the  reason  of  the 
cancel  (free  text) 

8.9.4  NETN_  RejectOfferConvoy 

A  NETN_RejectOfferConvoy  interaction  shall  be  sent  by  a  service  Consumer  federate  to  refuse  a 
NETN_OfferConvoy  interaction  (inherited  parameters  written  in  italics): 


|  HLAinteractionRoot.NETN Service.NETN RejectOffer.NETN RejectOfferConvoy 

Parameter 

Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN Eventldentifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Convoy  =  3 

Reason 

HLAASCIIstring 

Optional 
(Default: 
empty  String) 

Allows  to  inform  about  the  reason  of  the 
reject  (free  text) 

8.9.5  NETN_  ConvoyEmbarkmentStatus 

A  NETN_ConvoyEmbarkmentStatus  interaction  shall  be  sent  by  a  service  Provider  federate  to  inform  a 
service  Consumer  of  the  embarkment  state,  after  a  NETN_ServiceStarted  interaction  (inherited 
parameters  written  in  italics): 


|  HLAinteractionRoot.NETN Service.NETN ConvoyEmbarkmentStatus 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN Eventldentifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Convoy  =  3 

List  of 

ListOfObjectEmbarked 

N  ETN_ArrayOfObject 
Definition 

element 
embarked  by 
the  provider 

Allows  to  follow  the  elements 
managed  by  the  provider 

TransportUnitldentifier 

NETN_Callsign 

Identifier  of 
transporter 

Callsign  of  transporter 

8,9,6  NETN_  ConvoyDisembarkmentStatus 

A  NETN_ConvoyDisembarkmentStatus  interaction  shall  be  sent  by  a  service  Provider  federate  to  inform 
a  service  Consumer  of  the  disembarkment  state,  after  a  NETN_ServiceStarted  interaction  (inherited 
parameters  written  in  italics): 


Full  Name 


HLAinteractionRoot.NETN Service.NETN ConvoyDisembarkmentStatus 


Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN Eventldentifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN_Callsign 

Not  optional 

Entity  that  has  requested  the 
service 

Provider 

NETN_Callsign 

Not  optional 

Providing  or  intended  provider 
entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Convoy 
=  3 

ListOfObjectDisem  barked 

NETN_ArrayOfObject 

Definition 

List  of 

element 

disembarked 
by  the 
provider 

Allows  to  follow  the  elements 
managed  by  the  provider 

TransportUnitldentifier 

NETN_Callsign 

Identifier  of 
transporter 

Callsign  of  transporter 

8.9.7  NETN_ConvoyDestroyedEntities 

A  NETN_ConvoyDestroyedEntities  interaction  is  used  by  a  service  Provider  federate  to  give  information 
to  the  Consumer  on  managed  elements.  This  interaction  is  only  used  if  the  Provider  simulates 
destruction  of  managed  elements  (inherited  parameters  written  in  italics): 


|  HLAinteractionRoot.NETN Service.NETN ConvoyDestroyedEntities 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN  E  ven  tlden  tifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Convoy  =  3 

ListOfEmbarkedObje 

ctDestroyed 

N  ETN_ArrayOfObjectDe 
finition 

List  of  element 
destroyed 
during  the 
convoy 

Allows  to  follow  the  elements 
managed  by  the  provider 

8.9.8  NETN_RequestSupply 

A  request  for  supply  is  initiated  by  a  NETN_RequestSupply  interaction  with  the  following  parameters 
(inherited  parameters  written  in  italics): 


|  HLAinteractionRoot.NETN Service.NETN RequestService.NETN RequestSupply 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN Eventldentifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Supply  =  1 

RequestTimeOut 

HLAinteger64BE 

Optional 

Specifies  an  absolute  deadline 
(date/time)  for  the  provider  response. 
Number  of  second  since  01/01/1970 

SuppliesData 

SupplyArray 

List  of  type  and  quantity  of  supplies 
requested. 

LoadingDoneByPro 

HLABoolean 

Optional 

Determines  whether  the  service 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

vider 

(Default  = 
true) 

provider  (LoadingDoneByProvider  = 
true)  or  the  service  consumer 
(LoadingDoneByProvider  =  false)  takes 
care  of  the  (un)loading  of  the  material 

Note  that  if  the  time  specified  in  the  RequestTimeOut  passes  without  the  Provider  sending  an 
NETN_OfferSupply,  then  the  Consumer  will  send  a  NETN_CancelService. 

Note  that  a  Consumer  can  ask  Supply  to  multiple  Providers  by  leaving  the  Provider  Callsign  empty. 

8.9,9  NETN_OfferSupply 

In  response  to  a  NETN_RequestSupply  interaction,  a  federate  simulating  the  service  providing  entity 
shall  send  a  NETN_OfferSupply  interaction,  with  following  content  (inherited  parameters  written  in 
italics): 


|  HLAinteractionRoot.NETN Service.NETN OfferService.NETN OfferSupply 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN  E  ven  tlden  tifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Supply  =  1 

IsOffering 

HLAboolean 

(Not  Optional) 

Defines  if  the  requested  service  is  offered 
(=true)  or  not  (=false) 

RequestTimeOut 

HLAinteger64BE 

Optional 

Specifies  an  absolute  deadline  (date/time) 
for  the  provider  response.  Number  of 
second  since  01/01/1970 

SuppliesData 

SupplyArray 

All  offered 
supplies  if 
isOffering  = 
true  otherwise 

Undefined 

List  of  type  and  quantity  of  supplies 
offered.  May  be  different  from  the  list  of 
requested  supplies. 

LoadingDoneByPro 

vider 

HLABoolean 

Optional 
(Default  =  true) 

Determines  whether  the  service  provider 
(LoadingDoneByProvider  =  true)  or  the 
service  consumer 

(LoadingDoneByProvider  =  false)  takes 
care  of  the  (un)loading  of  the  material 

The  following  agreements  pertain  to  the  NETN_OfferSupply  interaction: 

•  The  NETN_OfferSupply.SuppliesData  must  include  an  amount  less  than  or  equal  to  the  requested 
amount. 

•  The  provider  will  reserve  the  offered  amount  of  the  supplies  when  the  NETN_OfferSupply  is  sent 
and  not  "un-reserve"  them  unless  the  consumer  sends  a  NETN_RejectOffer  or  either  federate 
sends  a  NETN_CancelService. 

•  If  the  resupply  involves  an  aerial  refuelling,  and  if  the  Provider  sends  a  LoadingDoneByProvider  = 
false  value,  the  (provider)  tanker  aircraft  must  stay  in  its  existing  orbit  until  either  the  refuelling 
is  complete  or  the  consumer  sends  a  NETN_RejectOffer  or  either  federate  sends  a 

NETN  CancelService 


8.9,10  NETN_AcceptOffer/NETN_RejectOffer 

In  response  to  a  timely  (i.e.  one  sent  prior  to  the  RequestTimeOut  date/time)  NETN_OfferSupply 
interaction,  a  federate  simulating  the  service  consumer  entity  shall  respond  in  one  of  three  ways: 

•  If  the  provider  responds  with  the  NETN_OfferService  parameter  IsOffering  =  "false,  and  if  the 
request  was  not  a  multicast  request, "  the  pattern  terminates  and  the  consumer  must  seek  a 
new  provider. 

•  If  the  values  in  SuppliesData  and  LoadingDoneByProvider  are  acceptable,  the  consumer  will 
respond  with  a  NETN_AcceptOffer. 

•  If  the  values  in  SuppliesData  or  the  LoadingDoneByProvider  are  unacceptable,  the  consumer  will 
respond  with  a  NETN_RejectOffer. 


8.9.11  NETN_ReadyToReceiveSupply 

Subsequent  to  sending  a  NETN_AcceptOffer,  the  consumer  will,  when  ready  to  receive  transfer  of 
supplies,  initiate  a  NETN_ReadyToReceiveSupply  interaction. 


|  HLAinteractionRoot.NETN_Service.NETN_ReadyToReceiveService.NETN_ReadyToReceiveSupply 

3 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN Eventldentifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Supply  =  1 

IsOffering 

HLAbooiean 

(Not  Optional) 

Defines  if  the  requested  service  is  offered 
(=true)  or  not  (=false) 

RequestTimeOut 

HLAinteger64BE 

Optional 

Specifies  an  absolute  deadline  (date/time) 
for  the  provider  response.  Number  of 
second  since  01/01/1970 

SuppliesData 

SupplyArray 

List  of  type  and  quantity  of  supplies 
desired.  May  be  smaller  or  less  than  the  list 
of  requested  supplies. 

Note  that  the  number(s)  or  amount(s)  of  supplies  specified  by  the  consumer  in 
NETN_ReadyToReceiveSupply.SuppliesData  must  be  less  than  or  equal  to  the  NETN_OfferSupply 
number(s)  or  amount(s). 

8.9.12  NETN_SupplyComplete 

Subsequent  to  sending  a  NETN_ServiceStarted  interaction,  and  when  a  federate  simulating  the  service 
providing  entity  has  finished  transferring  the  agreed  upon  material,  the  provider  shall  send  a 
NETN_SupplyComplete  interaction,  with  following  content  (inherited  parameters  written  in  italics): 


|  HLAinteractionRoot.NETN Service.NETN ServiceComplete.NETN SupplyComplete 

Parameter 

Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN  E  ven  tlden  tifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Supply  =  1 

SuppliesData 

SupplyArray 

Not  optional 

List  of  type  and  quantity  of  supplies  actually 
transferred. 

One  of  two  events  may  occur  to  cause  the  amount  or  quantity  of  supplies  actually  delivered  to  be  less  or 
fewer  than  the  amount  of  supplies  specified  in  the  NETN_ReadyToReceiveSupply.SuppliesData: 

1.  The  Provider  object  may  die  or  be  destroyed.  If  this  occurs,  the  federate  simulating  the  provider 
object  will  initiate  the  NETN_SupplyComplete  interaction  with  the  SuppliesData  comprised  of 
supplies  transferred  prior  to  the  loss  of  the  Provider  object. 

2.  If  the  Consumer  object  dies  or  is  destroyed,  the  federate  simulating  the  consumer  object  will 
initiate  a  NETN_CancelService,  thereby  terminating  the  transfer  of  supplies.  Note  that  either 
federate  may  also  send  a  NETN_CancelService  for  reasons  unrelated  to  the  loss  of  a  consumer  or 
provider  object.  Regardless  of  the  reason,  if  a  NETN_CancelService  is  sent,  the  provider  will 
initiate  the  NETN_SupplyComplete  interaction  with  the  SuppliesData  comprised  of  supplies 
transferred  prior  to  the  NETN_CancelService. 

8.9,13  NETN_RequestStorage 

A  request  for  storing  supplies  is  initiated  by  a  NETN_RequestStorage  interaction  with  the  following 
parameters  (inherited  parameters  written  in  italics): 


|  HLAinteractionRoot.NETN Service.NETN RequestService.NETN RequestStorage 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN  E  Men  tlden  tifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Storage  =  4 

RequestTimeOut 

HLAinteger64BE 

Optional 

Defined  a  deadline  (date)  for  the  provider 
response.  Number  of  second  since 
01/01/1970 

SuppliesData 

SupplyArray 

Not  optional 

List  of  type  and  quantity  of  supplies 
requested  to  be  stored. 

LoadingDoneByPr 

ovider 

HLABoolean 

Optional 
(Default  = 
true) 

Determines  whether  the  service  provider 
(LoadingDoneByProvider  =  true)  or  the 
service  consumer 

(LoadingDoneByProvider  =  false)  takes 
care  of  the  (un)loading  of  the  material 

8.9.14  NETN_OfferStorage 

In  response  to  a  NETN_RequestStorage  interaction,  a  service  providing  federate  shall  send  a 
NETN_OfferStorage  interaction,  with  following  content  (inherited  parameters  written  in  italics): 


|  HLAinteractionRoot.NETN Service.NETN OfferService.NETN OfferStorage 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN  E  ven  tlden  tifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Storage  =  4 

IsOffering 

HLAboolean 

(Not  Optional) 

Defines  if  the  requested  service  is 
offered  (=true)  or  not  (=false) 

RequestTimeOut 

HLAinteger64BE 

Optional 

Defined  a  deadline  (date)  for  the 
provider  response.  Number  of  second 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

since  01/01/1970 

SuppliesData 

SupplyArray 

All  supplies 
offered  to  be 

stored  if 
isOffering  = 
true  otherwise 

Undefined 

List  of  type  and  quantity  of  supplies 
offered  to  be  stored.  May  be  different 
from  the  list  of  supplies  requested  to  be 
stored. 

LoadingDoneByPro 

vider 

HLABoolean 

Optional 
(Default  =  true) 

Determines  whether  the  service 
provider  (LoadingDoneByProvider  = 
true)  or  the  service  consumer 
(LoadingDoneByProvider  =  false)  takes 
care  of  the  (un)loading  of  the  material 

8.9.15  NETN_StorageStarted 

In  response  to  a  NETN_OfferReceived  interaction,  a  federate  simulating  the  service  providing  entity  shall 
send  a  NETN_StorageStarted  interaction,  with  following  content  (inherited  parameters  written  in  italics): 


|  HLAinteractionRoot.NETN Service.NETN ServiceStarted.NETN StorageStarted 

Parameter  Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN  E  ven  tlden  tifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Storage  =  4 

List  of  type  and  quantity  of  supplies  to  be 

SuppliesData 

SupplyArray 

Not  optional 

transferred.  May  be  different  from  the 
list  of  supplies  offered  to  be  stored. 

8,9,16  NETN_RequestRepair 

The  request  for  repair  of  a  platform  is  initiated  by  a  NETN_RequestRepair  interaction  with  the  following 
parameters  (inherited  parameters  written  in  italics): 


Full  Name 


HLAinteractionRoot.NETN Service.NETN RequestService.NETN RequestRepair 


Parameter 

Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN Eventldentifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Repair  =  2 

RequestTimeOut 

HLAinteger64BE 

Optional 

Defined  a  deadline  (date)  for  the  provider 
response.  Number  of  second  since  01/01/1970 

RepairData 

RepairList 

Not  optional 

List  of  all  requested  repairs. 

8.9,17  NETN_OfferRepair 

In  response  to  a  NETN_RequestRepair  interaction,  a  federate  simulating  the  service  providing  entity 
shall  send  a  NETN_OfferRepair  interaction,  with  following  content  (inherited  parameters  written  in 
italics): 


|  HLAinteractionRoot.NETN Service.NETN OfferService.NETN OfferRepair 

Parameter 

Name 

Datatype 

Default  Value 
(if  optional) 

Definition 

ServicelD 

NETN  E  ven  tlden  tifier 

Not  optional 

Unique  identifier  for  a  service 

Consumer 

NETN Callsign 

Not  optional 

Entity  that  has  requested  the  service 

Provider 

NETN Callsign 

Not  optional 

Providing  or  intended  provider  entity 

ServiceType 

ServiceTypeEnum8 

Not  optional 

Type  of  requested  service.  Repair  =  2 

IsOffering 

HLAbooiean 

(Not  Optional) 

Defines  if  the  requested  service  is  offered 
(=true)  or  not  (=false) 

RequestTimeOut 

HLAinteger64BE 

Optional 

Defined  a  deadline  (date)  for  the  provider 
response.  Number  of  second  since  01/01/1970 

RepairData 

RepairList 

List  of  all 
offered  repairs 
if  isOffering  = 
true  otherwise 

Undefined 

List  of  the  type  of  repairs  offered.  May  be 
different  from  the  list  of  requested  repairs. 

8.10  Fixed  Record  Datatypes 


8.10.1  NETN_Ob  j  ectDefinitiontStruct 


Name 

NETN ObjectDefinitiontStruct 

Encoding 

HLAfixed  Record 

Definition 

Parameter  Is 

slame 

Datatype 

Default 

Value 

Definition 

ObjectCallsign 

NETN_Callsign 

No 

Callsign  of  the  object  (entity  or  aggregate) 
to  embark 

ObjectUniquelD 

NETNJJniquelD 

Optional 

Optional  ID  usable  to  reference  a 
published  entity.  This  attributes  must  be 
specified  if  an  HLA  instance  exist. 

ObjectFeature 

NETN ObjectFeatureStruct 

No 

Detail  of  the  object  to  embark 

8.10.2  NETN_ObjectDescription 


Name 

NETN ObjectDescription 

Encoding 

HLAfixed  Record 

Definition 

Parameter 

Name 

Datatype 

Default  Value 

Definition 

Type 

HLAASCIIString 

"Unknown" 

Weight 

NETN Float32BE 

No 

Weight  of  object  to  embark  (in  kg). 

Volume 

NETN Float32BE 

No 

Volume  of  object  to  embark  (in  m3) 

8.10.3  NETN_HumanDescription 


Name 

NETN Human  Description 

Encoding 

HLAfixed  Record 

Definition 

Parameter 

Name 

Datatype 

Default  Value 

Definition 

HumanType 

EntityTypeStruct 

The  type  of  human  defined  by  federate 
requesting  the  service 

Quantity 

NETN lntegerl6BE 

The  number  of  person  of  the  human 

type. 

Injury 

lnjuryTypeEnum8 

Degree  of  injury 

8.10.4  NETN_EquipDescription 


(Marne 

NETN EquipDescription 

Encoding 

HLAfixed  Record 

Definition 

Parameter 

Name 

Datatype 

Default  Value 

Definition 

EquipType 

EntityTypeStruct 

The  type  of  equipment 

Quantity 

NETN lnteger32BE 

The  number  of  units  of  the  Equip  type. 

DamageState 

DamageStatusEnum32 

Degree  of  damage 

8.10.5 


NETN_PlatformDescription 


Name 

NETN PlatformDescription 

Encoding 

HLAfixed  Record 

Definition 

Paramete 

Name 

?r 

Datatype 

Default  Value 

Definition 

PlatformType 

EntityTypeStruct 

The  type  of  equipment 

DamageState 

DamageStatusEnum32 

Degree  of  damage 

8.10.6  NETN.DataTStruct 


Name 

N  ETN DataTStruct 

Encoding 

HLAfixed  Record 

Definition 

Parameter 

Name 

Datatype 

Default  Value 

Definition 

ObjectToManaged 

NETN ArrayOfObjectDefinition 

Appointment 

NETN AppointmentStruct 

FinalAppointment 

NETN AppointmentStruct 

8.10.7  NETN.DataEDStruct 


Name 

NETN DataEDStruct 

Encoding 

HLAfixed  Record 

Definition 

Parameter  Name 

Datatype 

Default  Value 

Definition 

ObjectToManaged 

NETN ArrayOfObjectDefinition 

Appointment 

NETN AppointmentStruct 

8.10.8  NETN_AppointmentStruct 


Name 

NETN AppointmentStruct 

Encoding 

HLAfixed  Record 

Definition 
Parameter  Name 


Datatype 


Default  Value 


Definition 


Parameter  Name 

Datatype 

Default  Value 

Definition 

DateTime 

HLAinteger64BE 

No 

Number  of  second  since  1 
januaryl970 

Location 

World  LocationStruct 

No 

Location 

8.10.9 


RepairStruct 


Name 

Encoding 

Definition 


RepairStruct 


HLAfixed  Record 


Repairs  associated  with  a  specific  material 


Parameter 

Name 

Datatype 

Default  Value 

Definition 

MateriallD 

NETN UniquelD 

HLA  object  id  for  the  material. 

Repairs 

RepairTypeList 

List  of  the  types  of  repair  associated 
with  the  material. 

8.10.10 

SupplyStruct 

Name 

SupplyStruct 

Encoding 

HLAfixed  Record 

Definition 

Parameter 

Name 

Datatype 

Default  Value 

Definition  | 

SupplyType 


EntityTypeStruct 


The  type  of  supply 


Quantity 


NETN  Float32BE 


The  number  of  units  of  the  supply  type. 
The  unit  measure  depends  on  the 
supply  type  and  shall  use  the  SI  units  of 
measurement  used  for  such  supplies. 


8.11  Array  Datatypes 


Name 

Datatype 

Cardinality 

Encoding 

Definition 

RepairList 

RepairStruct 

Dynamic 

HLAvariableArray 

List  of  repair  descriptions 
(equipment  and  type  of 
repairs). 

RepairTypeList 

RepairTypeEnu 

ml6 

Dynamic 

HLAvariableArray 

List  of  repair  types. 

SupplyArray 

SupplyStruct 

Dynamic 

HLAvariableArray 

N  ETN_ArrayOfObjectDe 
finition 

NETN_ObjectD 

efinitionStruct 

Dynamic 

HLAvariableArray 

8.12  Enumerated  Datatypes 

8.12.1  ServiceTypeEnum8  datatype 


(Marne 

ServiceTypeEnum8 

Representation 

H  LAoctet 

Definition 

- 

Enumerate 

Value 

Definition 

Other 

0 

Resupply 

1 

Repair 

2 

Storage 

3 

Convoy 

4 

8.12.2  NETN_ConvoyTypeEnum32 


Name 

NETN ConvoyTypeEnum32 

Representation 

HLAinteger32Be 

Definition 

- 

Enumerate 

value 

Definition 

Transport 

0 

For  a  transport  service 

Embarkment 

1 

For  a  Embarkment  service 

Disembarkment 

2 

For  a  Disembarkment  service 

8.12.3 


NETN_OfferTypeEnum32 


(Marne 

NETN OfferTypeEnum32 

Representation 

HLAinteger32BE 

Definition 

- 

Enumerate 


RequestAcknowledgeWith  Restriction 


Value 


Definition 


Partially  Compliant  in  accordance  of  the  request 


RequestAcknowledgePositive 


Full  compliant 


RequestAcknowledgeNegative 


Not  compliant 


8.12.4  NETN_FeatureLevelEnum32 


Name 

NETN FeatureLevelEnum32 

Representation 

HLAinteger32BE 

Definition 

- 

Enumerate 

value 

Definition 

NoDetail 

0 

EntityDetail Other 

1 

EntityDetail Human 

2 

EntityDetail Equipment 

3 

EntityDetail Platform 

4 

AggregateDetail 

5 

8.13  Variant  Record  Datatypes 


8.13.1  NETN_TransportStruct 


(Marne 

N  ETN T  ra  nsportStruct 

Discriminant  Name 

ConvoyType 

Discriminant  Type 

NETN ConvoyTypeEnum32 

Encoding 

HLAvariantRecord 

Definition 

Discriminant 

Enum 

Parameter 

Datatype 

Default 

Value 

Definition 

Transport 

dataTransport 

N  ETN_DataTStruct 

Present  only  if  ConvoyType  = 
Transport 

Embarkment 

dataEmbarkment 

NETN_DataEDStruct 

Present  only  if  ConvoyType  = 
Embarkment 

Disembarkment 

dataDebarkment 

NETN_DataEDStruct 

Present  only  if  ConvoyType  = 
Disembarkment 

8.13.2  NETN_ObjectFeatureStruct 


Name 

NETN ObjectFeatureStruct 

Discriminant  Name 

FeatureLevel 

Discriminant  Type 

NETN FeatureLevelEnum32 

Encoding 

HLAvariantRecord 

Definition 

Discriminant  Enum 

Parameter 

Datatype 

Default 

Value 

Definition 

AggregateDetail 

SubObjectList 

NETN_ArrayOfObjectDefi 

nition 

No 

Present  only  if 
FeatureDescription  Level 
equals  "AggregateDetail" 

EntityDetail_Other 

ObjectDetail 

NETN_ObjectDescription 

No 

Present  only  if 
FeatureDescriptionLevel 
equals  "EntityDetail Other" 

EntityDetail_Human 

HumanDetail 

NETN_Human  Description 

No 

Present  only  if 

FeatureDescriptionLevel 

equals 

"EntityDetail Human" 

EntityDetail_Equipm 

ent 

EquipDetail 

NETN_EquipDescription 

No 

Present  only  if 

FeatureDescriptionLevel 

equals 

"EntityDetail Equipment" 

EntityDetail_Platfor 

m 

PlatformDetail 

NETN_PlatformDescriptio 

n 

No 

Present  only  if 

FeatureDescriptionLevel 

equals 

"EntityDetail Platform" 

9  NETN  Aggregate  Unit  FOM  Module  vl.O 

9.1  Introduction 

The  NETN  Aggregated  Unit  Representation  FOM  Module  documents  extensions  to  the  RPR-FOM  v2.0 
D17  FOM  Module  necessary  for  representation  and  use  of  aggregate  units  in  the  NETN.  The  chapter 
starts  by  documenting  NETN  Object  Classes  as  extensions  to  RPR-FOM  v2.0  classes  and  federation 
agreements  regarding  the  use  of  the  object  classes. 

It  then  discusses  methods  of  adjudicating  combat  between  objects  owned  by  different  federates  and 
concludes  by  identifying  necessary  extensions  to  interactions. 

9.2  NETN  Aggregated  Unit  Object  Classes 
9.2.1  NETN_Aggregate 

The  NETN_Aggregate  object  class  is  a  subclass  of  the  RPR  FOM  class  BaseEntity.AggregateEntity.  The 
table  below  describes  the  attributes,  data  types,  and  semantics  for  the  NETN_Aggregate  class.  Inherited 
attributes  are  shown  in  italics. 


Attribute  (Optional) 

Datatype 

Default  Value 
(If  optional) 

Definition 

Usage 

Entityldentifier 

En  titylden  tifierStruct 

(Not  Optional) 

Identifies  the  site,  application, 
and  entity  number  of  this  object 
instance.  It  is  used  for  group 
addressing  in  the  SIMAN 
interactions. 

Required 

EntityType 

EntityTypeStruct 

(Not  Optional) 

Kind ,  Country >  Domain , 

Category ,  Subcategory , 

Specific and  Extra  fields  of  the 
DIS  Entity  Type. 

Required 

IsPartOf 

IsPartOfStruct 

All  zeros 

Used  to  indicate  that  there  is  a 
spatial  relationship  between  this 
entity  and  a  host  entity,  i.e.,  one 
entity  is  "part  of"  another 

RelativeSpatial 

SpatiaiStruct 

All  zeros 

Used  to  express  the  spatial 
relationship  between  the  entity 
and  a  host  entity.  Used  in 
addition  to  the  normal  spatial 
attribute  which  describes 

absolute  location. 

Spatial 

SpatiaiStruct 

(Not  Optional) 

Used  to  express  the  spatial 
relationship  between  the  entity 
and  the  center  of  the  Earth. 

Required 

AggregateMarking 

AggregateMarkingStru 

ct 

All  zeros 

A  unique  marking  or 
combination  of  characters  used 
to  distinguish  the  aggregate 
from  other  aggregates. 

AggregateState 

AggregateStateEnum8 

(Not  Optional) 

An  indicator  of  the  extent  of 
association  of  objects  form  an 
operating  group. 

Required 
(see  FA1) 

Dimensions 

DimensionStruct 

(Not  Optional) 

The  size  of  the  area  covered  by 
the  units  in  the  aggregate. 

Required 

En  titylden  ti  tiers 

RTIObjectldArrayStru 

ct 

( Not  Optional) 

The  identification  of  entities 
that  are  contained  within  the 
aggregate. 

Required 
(see  FA2) 

Forceldentifier 

ForceldentifierEnum8 

(Not  Optional) 

The  identification  of  the  force 

Required 

Attribute  (Optional) 

Datatype 

Default  Value 
(If  optional) 

Definition 

Usage 

that  the  aggregate  belongs  to. 

Formation 

FormationEnum32 

(Not  Optional) 

The  category  of  positional 
arrangement  of  the  entities 
within  the  aggregate. 

Required 
(see  FA2) 

NumberOfSilentEntit 

ies 

short 

(Not  Optional) 

The  number  of  elements  in  the 
SilentEntities  list 

Required 
(see  FA3) 

NumberOfVariableD 

atums 

unsigned  long 

0 

The  number  of  records  in  the 
Variable  Datum  structure 

Not 

currently 

used 

SilentAggregates 

SilentAggregateStruct 

(Not  Optional) 

The  numbers  and  types,  of  silent 
aggregates  contained  in  the 
aggregate.  Silent  aggregates  are 
sub-aggregates  that  are  in  the 
aggregate,  but  that  are  not 
separately  represented  in  the 
virtual  world. 

Required 
(see  FA2) 

SilentEntities 

SilentEntityStruct 

(Not  Optional) 

The  numbers  and  types,  of  silent 
entities  in  the  aggregate.  Silent 
entities  are  entities  that  are  in 
the  aggregate,  but  that  are  not 
separately  represented  in  the 
virtual  world. 

Required 
(see  FA2) 

SubAggregateldentif 

ier 

RTIObjectldArrayStruct 

(Not  Optional) 

The  identifications  of  aggregates 
represented  in  the  virtual  world 
that  are  contained  in  the 
aggregate. 

Required 
(see  FA2) 

VariableDatums 

VariableDatumStruct 

Extra  data  that  describes  the 
aggregate. 

Not 

currently 

used 

Activity 

AggregateMissionEnum 

(Not  Optional) 

The  current  activity  of  the 
aggregate.  This  may  differ  from 
the  mission  due  to  casualties, 
readiness,  etc. 

Required 

Callsign 

HLAunicodeString 

(Not  Optional) 

The  name  of  the  object. 

Required 

CaptureStatus 

CaptureStatusEnum8 

0 

The  status  of  an  aggregate  with 
respect  to  its  control  or 
influence  over  its  own  activities. 

CombatValue 

NETN_Float64BE 

100 

A  summary  value  (in  percent)  of 
unit  effectiveness  based  on  level 
of  training,  leadership,  moral, 
personnel  and  equipment 
operational  status,  etc. 

CoverStatus 

CoverStatusStruct 

0 

Describes  the  unit's  protection 
from  the  effects  of  weapons  fire. 

Echelon 

EchelonEnum8 

(Not  Optional) 

The  level  of  command  of  the 
aggregate 

Required 

ElectronicSignature 

ElectronicSignatureStr 

uct 

Describes  the  aggregate's 
susceptibility  to  electronic 
detection  both  as  a  summary 
value  and  by  identifying 
aggregate  sensors  together  with 

Attribute  (Optional) 

Datatype 

Default  Value 
(If  optional) 

Definition 

Usage 

their  operational  status 

EmbeddedUnitList 

ArrayOfEmbeddedUnit 

The  list  of  objects  carried  by  this 
aggregate. 

EntityList 

EntityListVariableLeng 

th 

(Not  Optional) 

Provides  data  on  one  or  more 
entities  comprising  the 
aggregate.  This  includes  the 
initial  list  of  all  entities  and 
subsequent  updates  as  entities 
on  the  list  experience  change. 

This  attribute  is  optional  outside 
the  entity  Interest  Area  (IA),  but 
mandatory  inside  the  IA. 

Required 
within 
lAs  (see 

FA  2) 

Footprint 

WorldLocationStructA 

rray3 

The  region  occupied  by  the 
aggregate.  The  region  is  defined 
as  that  bounded  by  line 
segments  connecting  the  listed 
world  locations 

HigherHeadquarters 

NETN_UniquelD 

(Not  Optional) 

A  pointer  to  the  aggregate's 
superior  unit  or  headquarters. 

The  highest  level  unit  or 
headquarters  on  each  side  will 
publish  its  own  UniquelD  as  its 
HigherHeadquarters  value. 

Required 

HUMINTSignature 

HUMINTSignatureStru 

ct 

Describes  the  unit's 
susceptibility  to  human 
intelligence  (HUMINT),  i.e. 
"information  collected  and 
provided  by  human  sources." 

Mission 

MissionStruct 

(Not  Optional) 

The  operational  task  the 
aggregate  has  been  ordered  to 
perform,  the  time  the  mission 
was  assigned,  and  the  estimated 
completion  time. 

Required 

Mounted 

NETN_Float64BE 

(Not  Optional) 

The  percentage  of  aggregate 
personnel  traveling  on  or  in  their 
organic  transport. 

Required 

Sourcellnit 

HLAunicodeString 

0 

Aggregate  from  which  this 
aggregate  was  spawned. 

Status 

ActiveStatusEnum8 

1 

An  inactive  object  should  not  be 
shown  on  C4I  systems  and 
cannot  move  or  interact  with 
other  objects. 

SupportUnit 

SupportRelationshipSt 

ruct 

Identifies  unit(s)  which  support 
the  aggregate  logistically,  or 
with  a  specified  combat  or 
combat  support  relationship, 
e.g.  a  Direct  Support  or  General 
Support  Artillery  unit. 

Symbol 

HLAunicodeString 

(Not  Optional) 

The  APP6A  code  for  the 
aggregate. 

Required 

UniquelD 

NETN_UniquelD 

(Not  Optional) 

The  unique  identifier  of  the 
object. 

Required 

Attribute  (Optional) 

Datatype 

Default  Value 
(If  optional) 

Definition 

Usage 

UnitEquipment 

ResourceStatusArray 

(Not  Optional) 

This  summarizes  the  health 
status  of  the  equipment 
comprising  the  aggregate. 

Required 

UnitPersonnel 

ResourceStatusArray 

(Not  Optional) 

This  summarizes  the  health 
status  of  personnel  comprising 
the  aggregate. 

Required 

UnitSupplies 

SupplyStructArrayl 

(Not  Optional) 

The  type  and  quantities  of 
supplies  available  (on  hand)  to 
the  unit. 

Required 

VisualSignature 

VisualSignatureStructl 

00 

Describes  the  unit's 
susceptibility  to  electro-optical 
detection. 

WeaponsControlOrd 

er 

WeaponsControlOrder 

Enum8 

Describes  current  Weapon 

Control  Order  Free,  Tight,  or 

Hold. 

9.2.2  Federation  Agreements 

1.  A  federate  not  capable  of  or  not  intending  to  update  an  attribute  should  not  include  it 
in  its  declaration  set. 

2.  A  federate  may  request  ownership  of  un-owned  attributes  after  another  federate 
declares  its  objects. 

3.  A  federate  shall  not  update  an  attribute  unless  its  value  changes. 

4.  If  a  federation  intends  on  utilizing  this  FAD  and  accompanying  FOM  to  adjudicate 
combat,  all  attributes  shown  as  required  must  be  updated. 

5.  NETN  will  use  "Interest  Areas"  (IAs)  to  identify  areas  in  which  entity  level  data  must  be 
provided.  Outside  of  the  IAs  it  is  acceptable  for  aggregate  units  to  be  "fully"  aggregated,  i.e. 
AggregateStateEnum8  =  1,  though  (until  experimentation  proves  otherwise)  it  is  not  necessary 
that  they  be  "fully"  aggregated. 

6.  NETN  will  use  the  EntityList  attribute  within  IAs  rather  than  the  attributes: 

Entityldentifier,  SubAggregateldentifier,  NumberOfSilentEntities,  SilentEntities,  and 
SilentAggregates 

7.  This  attribute  is  intended  as  a  pointer  to  an  array  of  network  objects  of  relevance  to  the 
aggregate  but  the  network  object  itself  is  at  this  point  undefined. 

8.  We  will  use  both  WeaponFire  and  MunitionDetonation  for  all  except  mines  and  IEDs. 

9.  The  UniquelD  shall  be  used  in  the  Marking  field  as  well  as  in  the  attributes  and  parameters 
which  require  it. 

The  enumerated  DataTypes  used  in  NETN_Agg regate  are  further  defined  as  follows: 


9.3  Enumerated  Datatypes 
9.3.1  ActiveStatusEnum8 


Name 

Value 

Other 

0 

Active 

1 

Inactive 

2 

9.3.2  AggregateMissionEnuml6 

(from  JC3IEDM  action-event-category-code) 


Name 

Value 

Abdication 

1 

Name 


Value 


Accident 

2 

AccidentAircraftGround 

3 

Accident Mine 

4 

Accident Traffic 

5 

Accident Weapon 

6 

Accident Workplace 

7 

Advancing 

8 

AerialEngagement 

9 

AerialShootDown 

10 

AirAssault 

11 

AirborneAssault 

12 

AircraftCrash 

13 

AircraftLanding 

14 

AircraftLaunchActivity 

15 

AircraftLoss 

16 

AirspaceViolation 

17 

AlertCancellation 

18 

Ambush 

19 

AmphibiousOperation 

20 

ArmsProduction 

21 

ArmsTrade 

22 

Arresting Legal 

23 

ArrestingOrObstructing 

24 

Arson 

25 

ArtilleryFire 

26 

Assassination 

27 

Assembling 

28 

AssistingACriminal 

29 

AtmosphericPollution 

30 

Attack Deliberate 

31 

Attack Diversion 

32 

Attack Electronic 

33 

Attack Hasty 

34 

Attack Main 

35 

Attack NotOtherwiseSpecified 

36 

Attack Supporting 

37 

AttemptedMurder 

38 

AttemptedRape 

39 

Attempted  Robbery 

40 

AttemptedSuicide 

41 

Avoiding 

42 

BellyLanding 

43 

Blocking 

44 

Bombing 

45 

Bombing Accidental 

46 

Bombing Deliberate 

47 

Name 


Value 


BoobyTrapDiscovery 

48 

BorderCrossing Escorted 

49 

BorderCrossing Forced 

50 

BorderCrossingJIlegal 

51 

BorderCrossing Not-Planned 

52 

BorderCrossing Planned 

53 

BorderCrossing Surveilled 

54 

Borderlncursion 

55 

BorderRaid 

56 

Breaching 

57 

Build-Up 

58 

BurnedOutObject 

59 

Bypass 

60 

Canalise 

61 

Capture 

62 

CarrierLaunch 

63 

CarrierRecovery 

64 

CBRN-EVENT 

65 

CeremonyOrParade 

66 

Civil  DemonstrationJIlegal 

67 

Civil  Demonstration Legal 

68 

CivilDisobedience 

69 

CivilUnrest 

70 

CivilWar 

71 

Clearing Air 

72 

Clearing LandCombat 

73 

Clearing Obstacle 

74 

Clearing RadioNet 

75 

Codeword  Execution 

76 

Collision Mid-Air 

77 

Collision Obstacle 

78 

CommunicationsActivation 

79 

CommunicationsDeactivation 

80 

CommunicationsDisruption 

81 

Communicationslnterception 

82 

CommunicationsOutage 

83 

CommunicationsRestoration 

84 

ConductingConference 

85 

ConductingForwardPassageOf  Lines 

86 

ConductingMedia  Interview 

87 

ConductingPreparatoryFire 

88 

ConductingRearwardPassageOf  Lines 

89 

ConductingRecreationalActivities 

90 

ConductingRoadService 

91 

ConductingSocial  Events 

92 

ConductingSportingEvents 

93 

Name 


Value 


Confiscation 

94 

ConsolidatingOfAPosition 

95 

Constructing 

96 

Containing 

97 

Cooperating 

98 

CounterAttack 

99 

CounterAttackByFire 

100 

Counter-BatteryFire 

101 

CoupDetat 

102 

Covering 

103 

CrimeAgainstHumanity 

104 

Criminallncident 

105 

Crossing 

106 

Dazzle 

107 

Death NaturalCauses 

108 

DeathOfChiefOfState 

109 

DeathOfSpiritualLeader 

110 

Deception 

111 

Deception Electronic 

112 

Defeat 

113 

Defending 

114 

Deflecting 

115 

Delaying 

116 

Demolition 

117 

Demonstration 

118 

Denying 

119 

Deploying 

120 

Destroying 

121 

Disease 

122 

Disengaging 

123 

Disrupting 

124 

Distributing 

125 

Diversion 

126 

Drive-ByShooting 

127 

Drought 

128 

DrugConsumptionJIlegal 

129 

DrugDistributionJIlegal 

130 

DrugManufacturing lllegal 

131 

DrugOperation 

132 

DrugStorage 

133 

DrugTransportation 

134 

EarlyWarningAlert 

135 

Earthquake 

136 

ElectionAssociatedViolence 

137 

ElectronicEmission 

138 

ElectronicWarfare 

139 

Name 


Value 


EnemyContact 

140 

Engaging 

141 

Enveloping 

142 

Epidemic 

143 

EquipmentFailure 

144 

Escaping 

145 

Escorting 

146 

Evacuating 

147 

Execution 

148 

Exploitation 

149 

Explosion 

150 

Famine 

151 

Fire 

152 

Firefighting 

153 

Fix 

154 

Fix Acoustic 

155 

Fix Electromagnetic 

156 

Fix Electro-Optical 

157 

Flood 

158 

FollowingAndAssuming 

159 

FollowingAndSupporting 

160 

ForcedLanding 

161 

FriendlyFire 

162 

GeneratingChemicalSmoke 

163 

Genocide 

164 

GovernmentalCollapse 

165 

Guarding 

166 

Gunnery Air-To-Air 

167 

Harassing 

168 

Hiding 

169 

Hijacking Boat 

170 

Hijacking LandVehicle 

171 

Hijacking NotOtherwiseSpecified 

172 

Hijacking Plane 

173 

Hold Defensive 

174 

Hold Offensive 

175 

HostageTaking 

176 

HumanRightsViolation 

177 

Hunting 

178 

Identifying 

179 

Illumination 

180 

IndirectFire 

181 

IndiscriminateShooting 

182 

IndustrialEspionagelncident 

183 

Infiltration 

184 

Interception 

185 

Name 


Value 


Interdiction 

186 

Intimidation 

187 

Invasion 

188 

Isolation 

189 

IssuingMediaArticle 

190 

IssuingMedia  Documentary 

191 

IssuingPressRelease 

192 

Jamming 

193 

Kidnapping 

194 

LabourStrike 

195 

Leaguer 

196 

LetterBombExplosion 

197 

LetterBomblncident 

198 

LocalElection 

199 

Locating 

200 

Looting 

201 

Maintaining 

202 

Marking 

203 

MartialLawl  implementation 

204 

MassingOfForces 

205 

MassiveDeportationOrBanishment 

206 

MedicalEvacuation 

207 

MilitaryMobilisation 

208 

Mine-Laying 

209 

Missinglndividual 

210 

Missionstaging 

211 

MortarFire 

212 

Moving 

213 

Murder 

214 

MutualAssistancePactAgreement 

215 

NationalElection 

216 

NationalHoliday 

217 

NationalStateOf  Emergency 

218 

NaturalDisaster 

219 

NavalGunFire 

220 

Naval  Platform  FlightOperations 

221 

NetworkSeizure 

222 

Neutralize Chemical 

223 

Neutralize Combat 

224 

Neutralize Explosive 

225 

Obscure 

226 

Observing 

227 

Occupying 

228 

Oceans SeasOrWaterPollution 

229 

OffensiveOrCounteroffensive 

230 

OrganisedCrime 

231 

Name 

Value 

OutbreakOfRacialOrTribalOrEthnicWarfare 

232 

Patrolling 

233 

PeaceConference 

234 

PeaceT  reatyAgreement 

235 

Penetrating 

236 

Pestilence 

237 

Petroleum  ProductSpills 

238 

Picketing 

239 

Poisoning 

240 

Political  Demonstration 

241 

PoliticalExecution 

242 

POWReturn 

243 

PrisonerExchange 

244 

Procuring 

245 

Protection Electronic 

246 

ProvidingAccommodation 

247 

ProvidingAgriculturalSupport 

248 

ProvidingBedding 

249 

ProvidingCamps 

250 

ProvidingConstructionServices 

251 

ProvidingDecontaminationServices 

252 

ProvidingEducationServices 

253 

ProvidingHealthcareServices 

254 

ProvidingHostNationSupport 

255 

Providinglnfrastructure 

256 

ProvidingLaundryServices 

257 

ProvidingRepairServices 

258 

ProvidingSecurityServices 

259 

ProvidingShelter 

260 

ProvidingStorageServices 

261 

ProvidingTranshipmentServices 

262 

Proxy-Bombing 

263 

PsychologicalOperation 

264 

PublishingMediaArticle 

265 

PublishingMediaDocumentary 

266 

PublishingPressRelease 

267 

Pursuing 

268 

Rape 

269 

Reconnaissance 

270 

Reconnaissanceln  Force 

271 

Reconstituting 

272 

Recovering 

273 

Recuperating 

274 

Redeployment 

275 

RefugeeMovement 

276 

Reinforcing 

277 

Name 


Value 


RelieflnPlace 

278 

ReligiousDemonstration 

279 

ReligiousViolence 

280 

ReligiousWarfare 

281 

Rendezvous 

282 

Reorganising 

283 

Repairing 

284 

Resting 

285 

Resupplying 

286 

Retain 

287 

Retire 

288 

Revolution 

289 

Riot 

290 

Robbery 

291 

RocketFire 

292 

Sabotage 

293 

Screening 

294 

SecessionOfPortionOfCountry 

295 

Securing 

296 

SecurityCompromise 

297 

SecurityViolation 

298 

Seizing 

299 

ServingAsABreakoutForce 

300 

ServingAsABridgehead  Force 

301 

ServingAsAFIankGuard 

302 

ServingAsAMainBody 

303 

ServingAsAnAdvanceGuard 

304 

ServingAsAnln-PlaceForce 

305 

ServingAsARearGuard 

306 

ServingAsAReserve 

307 

SettingUp 

308 

Shooting 

309 

SniperAttack 

310 

SpaceAccident 

311 

Spying 

312 

StateOfWar 

313 

Strafing Aerial 

314 

Strike 

315 

Suicide 

316 

Supporting 

317 

Suppressing 

318 

Surrender 

319 

Surveillance Electronic 

320 

SuspensionOfHostilities 

321 

Terrorism 

322 

Threaten 

323 

Name 

Value 

Torture 

324 

Transporting 

325 

Traversing 

326 

TreatyViolation 

327 

Troublemaking Agitating 

328 

Troublemaking Bullying 

329 

Troublemaking Harassing 

330 

Troublemaking Hooliganism 

331 

Troublemaking lnciting 

332 

Troublemaking lntimidating 

333 

Turning 

334 

UnexplodedOrdnanceDiscovery 

335 

VandalismOrRapeOrLootOrRansackOrPlunderOrSack 

336 

Verifying 

337 

VesselSinking 

338 

VolcanicEruption 

339 

WarOrCrisisAlert 

340 

WarOrMilitaryConference 

341 

WarCrime 

342 

WeaponFiring 

343 

Withdrawal 

344 

Withdrawal  Underpressure 

345 

Witnessing 

346 

NotOtherwiseSpecified 

347 

9.3.3  CaptureStatus8 


Name 

Value 

Other 

0 

Not-Captured 

1 

Captured 

2 

AttemptingSurrender 

3 

AttemptingEscape 

4 

9.3.4  ConcealmentEnum8 


Name 

Value 

Invalid 

0 

InOpen 

1 

Mountedlnternally 

2 

MountedExternally 

3 

UnderNet 

4 

UnderGround 

5 

InsideStructure 

6 

FightingPositionCovered 

7 

FightingPosition  Uncovered 

8 

9.3.5  CoverEnum8 


Name 

Value 

Other 

0 

HastyFightingPositions 

1 

1  ndividual  FightingPositions 

2 

CrewServedWeaponsPositions 

3 

FightingPositionsWithOverheadCover 

4 

StrongPoints 

5 

9.3.6  DamageStatusEnhancedEnum32 


Name 

Value 

NoDamage 

0 

SlightDamage 

1 

ModerateDamage 

2 

SignificantDamage 

3 

Destroyed 

4 

9.3.7  EchelonEnum8  (from  JC3IEDM  echelon-size-code) 


Name 

Value 

Army 

1 

ArmyGroup 

2 

Battalion 

3 

BattalionGroup 

4 

BattleGroup 

5 

Brigade 

6 

BrigadeGroup 

7 

Company 

8 

CompanyGroup 

9 

Corps 

10 

Division 

11 

Fleet 

12 

Flight 

13 

Platoon 

14 

Regiment 

15 

Region 

16 

Section 

17 

Squad 

18 

SquadronAir 

19 

SquadronMaritime 

20 

TaskElementNavy 

21 

TaskForceNavy 

22 

TaskGroupNavy 

23 

TaskllnitNavy 

24 

TeamFireteamCrew 

25 

Wing 

26 

NotKnown 

27 

NotOtherwiseSpecified 

28 

9.3.8  EntityCategoryEnum8 


Name 

Value 

Invalid 

0 

EquipmentEntity 

1 

PersonnelEntity 

2 

EmitterEntity 

3 

RadioEntity 

4 

9.3.9  SensorStateEnum8 


Name 

Value 

Other 

0 

Off 

1 

OnButNotEmitting 

2 

OnAndEmitting 

3 

9.3.10  SupportRelationshipEnum8 


Name 

Value 

Other 

0 

Logistics 

1 

DirectSupportArtillery 

2 

DirectSupportReinforcingArtillery 

3 

GeneralSupportArtillery 

4 

Engineering 

5 

9.3.11  UpdateTypeEnum8 


Name 

Value 

Invalid 

0 

Create 

1 

Update 

2 

Addition 

3 

Delete 

4 

9.3.12  WeaponsControlOrderEnum8 


Name 

Value 

Other 

0 

WeaponsFree 

1 

WeaponsTight 

2 

WeaponsHold 

3 

9.4  Complex  Datatypes 
9.4.1  CoverStatusStruct 


Name 

Type 

Semantics 

CoverStatusPercent 

NETN  Percentage 

The  percentage  of  protection  enjoyed  by  an  aggregate.  A  unit 
with  100  percent  cover  would  be  impervious  to  the  effects  of 

Name 

Type 

Semantics 

weapons  fire 

CoverTypeEnum 

CoverEnum8 

An  optional  field  describing  the  type  of  cover  employed  by  the 
aggregate 

9.4.2  ElectronicSignatureStruct 


Name 

Type 

Semantics 

ElectronicSignaturePercent 

NETNPercentage 

A  summary  percentage  of  an  aggregates 
susceptibility  to  detection  of  its  electronic  emissions. 
Zero  percent  means  that  the  aggregate  has  no 
electronic  emissions. 

SensorArray 

SensorStructArrayl 

A  list  of  sensors  owned  by  the  aggregate  together 
with  their  respective  operational  status  and  range. 

9.4.3  EntityListStruct 

An  array  of  elements  of  Datatype  EntityStruct  with  cardinality  1+ 


9.4.4  EntityStruct 


Name 

Type 

Semantics 

Callsign 

HLAunicodeString 

The  name  of  the  object. 

EntityCategory 

EntityCategoryEnum32 

Indicates  whether  the  entity  is  equipment,  person, 
emitter,  etc. 

EntityStatus 

DamageStatusEnhancedEnum32 

The  damage  state  of  the  entity. 

IsDistinctObject 

OMT13boolean 

OPTIONAL.  A  BaseEntity  object  has  been  created  to 
represent  this  entity  (true)  or  not  (false). 

Isllnavailable 

OMT13boolean 

OPTIONAL.  This  entity  is  in  use  by  another  object 
(true)  or  not  (false). 

Facing 

Floatl5 

OPTIONAL.  Direction  is  measured  in  degrees 
clockwise  from  orientation  of  unit 

Concealment 

ConcealmentEnum32 

OPTIONAL.  Indicates  whether  the  entity  is 
concealed  and,  if  so,  how 

OffsetLocation 

RelativePositionStruct 

The  entity  location  given  as  an  offset  from  the 
location  of  the  aggregate  unit  in  meters. 

Note:  Padding  check  needed  after  Callsign 


9.4.5  EntityListVariableArrayStruct 


Name 

Type 

Semantics 

Update  Type 

UpdateTypeEnum32 

Indicates  whether  this  update  creates  the  list  or  modifies  its' 
values. 

EntityList 

EntityListStruct 

Data  about  one  or  more  entities  comprising  the  list. 

9.4.6  HUMINTSignatureStruct 


Name 

Type 

Semantics 

HUMINTSignaturePercent 

NETNPercentage 

A  summary  percentage  of  an  aggregates  susceptibility 
to  detection  by  human  intelligence  collectors.  Zero 
percent  signature  means  an  aggregate  is  impervious  to 
HUMINT. 

9.4.7  MissionStruct 


Name 

Type 

Semantics 

StartTime 

DateTime 

An  optional  field  providing  the  mission  start  time 

Name 

Type 

Semantics 

EndTime 

DateTime 

An  optional  field  providing  the  mission  estimated  end  time 

MissionEnum 

AggregateMissionEnuml6 

The  mission  assigned  to  the  aggregate 

9.4.8  NetworkList 

An  array  of  elements  of  DataType  HLAunicodeString  with  cardinality  0+.  Note:  Padding  check  needed 
after  each  element  (except  final  element). 


9.4.9  ResourceStatusNumber 


Name 

Type 

Semantics 

NumberHealthyOrlntact 

NETN Float64BE 

The  number  of  healthy  or  intact  resources 

NumberSlightlyDamaged 

NETN Float64BE 

The  number  of  slightly  damaged  resources 

NumberModeratelyDamaged 

NETN Float64BE 

The  number  of  moderately  damaged  resources 

NumberSignificantlyDamaged 

NETN Float64BE 

The  number  of  significantly  damaged  resources 

NumberDestroyed 

NETN Float64BE 

The  number  of  destroyed  or  consumed  resources 

ResourceName 

HLAunicodeString 

The  name  of  the  resource 

9.4.10  SensorStructArrayl 

An  array  of  elements  of  DataType  SensorStruct  with  cardinality  1+ 


9.4.11  SensorStruct 


Name 

Type 

Semantics 

SensorStateEnum 

SensorStateEnum32 

The  operational  status  of  the  sensor 

SensorDamageState 

DamageStatusEnum32 

The  damage  status  of  the  sensor 

SensorCoverage 

Float2 

The  maximum  range  of  the  sensor 

SensorlD 

HLAunicodeString 

A  sensor  owned  by  the  aggregate 

9.4.12  SupportRelationshipStruct 


Name 

Type 

Semantics 

SupportConsumer 

NETN UniquelD 

The  unique  ID  of  the  consumer  of  the  support. 

SupportProvider 

NETN UniquelD 

The  unique  ID  of  the  provider  of  the  support. 

SupportType 

SupportRelationshipEnum8 

The  type  of  support  provided  by  the  supporting  unit. 

Note:  Padding  chec 

k  needed  after  SupportConsumer 

9.4.13  VisualSignatureStruct 


Name 

Type 

Semantics 

DVOSignaturePercent 

NETN  Percentage 

A  summary  percentage  of  an  aggregates  susceptibility  to 
detection  by  direct  view  optics,  i.e.  the  human  eye, 
binoculars,  or  telescopes.  A  unit  with  zero  percent 
signature  would  be  concealed  from  DVO  detection. 

l2SignaturePercent 

NETN  Percentage 

A  summary  percentage  of  an  aggregates  susceptibility  to 
detection  by  Image  Intensifying  sensors.  A  unit  with  zero 
percent  signature  would  be  invisable  to  image  intensifiers 
(12). 

ThermalSignaturePercent 

NETN  Percentage 

A  summary  percentage  of  an  aggregates  susceptibility  to 
detection  by  thermal  sensors.  A  unit  with  zero  percent 
signature  would  be  invisable  to  thermal  sensors. 

9.4.14  WorldLocationStructArray2 

An  Array  of  element  type  WorldLocationStruct  with  cardinality  3+ 


9.4.15  WorldLocationStruct 


Name 

Type 

Semantics 

X 

Double2 

Distance  in  meters  from  the  center  of  the  earth  projecting  through  0  degrees  latitude 
and  0  degrees  longitude. 

Y 

Double2 

Distance  in  meters  from  the  center  of  the  earth  projecting  through  90  degrees  east 
longitude  and  0  degrees  latitude. 

Z 

Double2 

Distance  in  meters  from  the  center  of  the  earth  projecting  through  the  geographic  North 
Pole. 

9. 5  En tity  Object  Class  Extensions 

9.5.1  RPR-FOM  Platform  Object  Class  Extension 

The  following  RPR-FOM  platform  object  class  extensions  have  been  made: 


Full  Name 


HLAobjectRoot.BaseEntity.  Physical  Entity.  Platform. Aircraft.  NETN_Aircraft _ 

HLAobjectRoot.  BaseEntity.Physical  Entity.  Platform.  AmphibiousVehicle.NETN_AmphibiousVehicle 
HLAobjectRoot.BaseEntity.  Physical  Entity.  Platform. GroundVehicle.NETN_GroundVehicle 
HLAobjectRoot.  BaseEntity.Physical  Entity.  Platform.  MultiDomain  Platform.  NETN_MultiDomain  Platform 
HLAobjectRoot.  BaseEntity.Physical  Entity.  Platform. Spacecraft.  NETN_Spacecraft _ 

HLAobjectRoot.  BaseEntity.Physical  Entity.  Platform.  SubmersibleVessel.NETN_SubmersibleVessel 
HLAobjectRoot.  BaseEntity.Physical  Entity.  Platform. SurfaceVessel.NETN SurfaceVessel 


All  of  the  above  extensions  include  the  following  attributes: 


Attribute 

Data  Type 

Default  Value 
(If  Optional) 

Semantics 

Usage 

Activity 

AggregateMission 

Enuml6 

(Not  Optional) 

The  activity  of  the  object. 

Required 

Callsign 

HLAunicodeString 

(Not  Optional) 

The  name  of  the  object. 

Required 

Embedded 

UnitList 

ArrayOfEmbedded 

Unit 

0 

List  of  unique  IDs  of  on¬ 
board  elements 

Status 

AggregateStatusE 

num8 

1 

If  an  instance  shall  be  taken 
into  account  by  federates 

9,5.2  RPR-FOM  Lifeform  Object  Class  Extension 

The  following  RPR-FOM  lifeform  object  class  extensions  have  been  made: 


Full  Name 


HLAobjectRoot.  BaseEntity.Physical  Entity.  Lifeform.  Human.  NETNJHuman 
HLAobjectRoot.  BaseEntity.Physical  Entity.  Lifeform.  NonHuman.NETN NonHuman 


All  of  the  above  extensions  include  the  following  attributes: 


Attribute 

Data  Type 

Semantics 

Callsign 

HLAunicodeString 

The  name  of  the  object. 

Status 

AggregateStatusEnum8 

If  an  instance  shall  be  taken  into  account  by  federates 

Activity 

AggregateMission  Enum  16 

The  activity  of  the  object. 

9.6  Combat  adjudication 


This  section  discusses  combat  adjudication  between  objects  owned  by  different  federates.  This  design 
pattern  has  not  been  verified  by  MSG-068  but  is  included  here  as  a  reference.  Any  use  of  this  design 
pattern  should  consider  the  fact  it  has  not  been  thouroghly  tested. 

Use  cases  are  defined  as  follows  to  decompose  the  problem: 

"Case  1"  consists  of  two  federates  which  both  publish  and  subscribe  to  Platform  object  A  "platform 
object"  is  any  of  the  BaseEntity.PhysicalEntity.Platform  subclasses  belonging  to  the  NETN_Aggregate 
FOM,  e.g.  BaseEntity.PhysicalEntity.Platform.GroundVehicle.NETN_GroundVehicle  sub-classes.  This  case 
is  addressed  by  the  existing  RPR  FOM  WeaponFire  and  MunitionDetonation  interactions. 

"Case  2"  consists  of  two  federates  which  both  publish  and  subscribe  to  the  NETN_Aggregate  object  class. 
This  case  requires  extensions  as  follows: 

A.  Case  2A  involves  ground-to-ground  combat  (between  two  Aggregate  objects  owned  by  different 
federates).  The  section  below  entitled  "Combat  Adjudication  Service  Federate  (CASF)"  proposes 
a  means  for  avoiding  the  "fair  fight"  problems  caused  by  modeling  differences  between  the 
federates  which  may  give  an  unfair  advantage  to  objects  owned  by  one  federate  over  those 
owned  by  the  other. 

B.  Case  2B  involves  an  engagement  between  objects  usually  modeled  as  entities  (even  in  an 
"aggregate"  simulation)  and  an  aggregate.  If  this  is  an  inaccurate  assumption,  that  is  if  a  federate 
is  unable  to  publish  and  subscribe  to  ships  and  aircraft  as  platform  objects,  other  extensions  to 
the  BaseEntity.AggregateEntity  class  will  probably  be  necessary.  For  example,  a  ship  fires  naval 
gunfire  at  a  ground  unit  or  an  attack  helicopter  firing  an  AGM-114  Hellfire  missile(s)  at  a  tank  in  a 
mechanized  task  force  comprised  of  tanks,  infantry  fighting  vehicles  (IFVs),  and  trucks.  The 
(relatively)  small  number  of  munitions  fired  in  such  an  engagement  recommends  use  of  the 
existing  RPR  FOM  interactions  with  an  extension  as  described  in  the  section  entitled 
NETN_MunitionDetonation  below. 

"Case  3"  consists  of  two  federates  which  publish  and  subscribe  to  dissimilar  object  types.  That  is,  one 
federate  publishes  and  subscribes  to  the  Platform  sub-class  and  the  other  publishes  and  subscribes  to 
the  NETN_Aggregate  object  class.  In  this  case  the  objects  owned  by  one  federate  may  not  acquire  the 
object(s)  owned  by  the  other  federate.  Without  acquisition,  conflict  is  impossible  even  in  circumstances 
where  combat  should  occur.  Engagements  in  this  case  will  be  resolved  through  use  of  the  "Combat 
Adjudication  Service  Federate  (CASF)." 

The  table  below  summarizes  the  proposed  approach  for  the  different  use  cases  and  engagement  types. 


Engagement  Type 

CASE  1 

CASE  2 

CASE  3 

Air-to-Air 

A2A 

Resolve  internal 

ny 

2B:  Resolve  internally 

CASF 

Air-to-Ground 

A2G 

Resolve  internal 

ny 

2B:  Resolve  internally 

CASF 

Air-to-Naval 

A2N 

Resolve  internal 

lly 

2B:  Resolve  internally 

CASF 

Ground-to-Air 

G2A 

Resolve  internal 

lly 

2B:  Resolve  internally 

CASF 

Ground-to-Ground 

Indirect  Fire  Only 

G2GI 

Resolve  interna 

ly 

2B:  Resolve  internally 

CASF 

Direct  Fire 

G2GD 

Resolve  interna 

iy 

Case  2A:  Use  CASF 

CASF 

Ground-to-Naval 

G2N 

Resolve  interna 

iy 

2B:  Resolve  internally 

CASF 

Naval-to-Air 

N2A 

Resolve  interna 

iy 

2B:  Resolve  internally 

CASF 

Naval-to-Ground 

N2G 

Resolve  interna 

iy 

2B:  Resolve  internally 

CASF 

Naval-to-Naval 

N2N 

Resolve  interna 

iy 

2B:  Resolve  internally 

CASF 

9.6.1  Combat  Adjudication  Service  Federate  (CASF) 


This  section  introduces  a  means  of  adjudicating  combat  engagements 
between: 

•  NETN_Aggregate  objects  owned  by  different  federates  (CASE  2A) 

•  a  NETN_Aggregate  owned  by  one  federate  and  one  or  more  platform-level  objects  are  owned  by 
another  federate  (CASE  3) 

A  federate  capable  of  adjudicating  ground-to-ground  combat,  hereafter  referred  to  as  the  Combat 
Adjudication  Service  Federate  (CASF),  must  subscribe  to  the  NETN_Aggregate  and  Platform  object 
classes.  The  CASF  must  also  utilize  the  NETN  Service  Consumer-Provider  pattern  as  follows: 

•  In  CASE  2 A,  if  a  NETN_Aggregate  owned  by  one  of  the  federates  acquires  a  NETN_Aggregate 
owned  by  the  other  federate  and  wishes  to  engage  it  in  combat,  it  will  initiate  a 
NETN_RequestService  interaction  to  which  the  CASF  must  respond  with  a  NETN_OfferService 
interaction. 

•  In  CASE  3,  CASF  will  initiate  a  N ETN_OfferService  interaction  offering  to  adjudicate  the  combat 
between  the  two  federates  whenever  two  or  more  objects  owned  by  different  federates  should 
engage  in  ground-to-ground  combat  according  to  its  (CASF's)  algorithms. 

Assuming  the  negotiation  process  results  with  a  NETN_AcceptOffer  interaction  (there  will  obviously  be 
several  assumptions  and  conditions  surrounding  this  service;  these  will  be  addressed  below),  the  CASF 
will  adjudicate  the  combat  according  to  its  algorithms  and  inform  the  owning  federates  of  adjudication 
results  and  ammunition  consumed,  ("inform  the  owning  federates"  is  used  because  of  the  current 
prohibition  against  shared  object  ownership.  Recommend  abolishing  that  constraint  and  enabling 
transfer  of  health  state  and  on-hand  supply  attributes  to  CASF  in  conjunction  with  initiating 
NETN_AcceptOffer  interaction). 

Assumptions: 

1.  CASF  is  able  to  utilize  the  NETN  Service  Consumer-Provider  pattern. 

2.  CASF  is  able  to  subscribe  to  both  platform  level  and  aggregate  level  object  classes  and  can 
adjudicate  the  combat  between  the  object  instances. 

3.  CASF  knows  enough  about  the  two  or  more  objects  to  be  able  to  adjudicate  combat  between 
them. 

What  is  the  minimum  set  of  required  attributes  necessary  to  satisfy  this  assumption? 

a.  For  all  entities  (platforms)  comprising  all  units  or  individual  platforms  involved  in  the  combat, 
the  following  attributes  could  be  important:  activity,  location,  mounted  state,  weapons 
control  order,  status  with  respect  to  health,  equipment,  ammunition,  capture,  cover,  and 
concealment  (from  the  different  sensor  types,  i.e.  the  signature  values  in  NETN_Aggregate). 

b.  The  objects  engaged  in  direct  fire  combat  maybe  supported  by  other  units,  a  supporting 
artillery  unit  for  example,  whose  support  and  weapons  expenditure  should  be  accounted  for 
by  CASF. 

4.  Both  federates  accept  the  NETN_OfferService  interaction.  An  exception,  below,  addresses  what 
to  do  if  one  or  more  federates  refuse  the  service  offer. 


Exceptions: 

1.  One  of  the  federates  refuses  the  NETN_OfferService  interaction.  Recommend  an  initial 
implementation  of  one  of  three  courses  of  action.  A  federate  which  refuses  the 
NETN_OfferService  interaction  must  necessarily  refuse  combat  by  one  of  means: 

a.  Retreat.  This  would  seem  particularly  appropriate  if  an  object  is  advancing,  is  notified 
that  it  is  in  danger  of  ground  combat,  and  chooses  to  retreat  along  its  route  of  advance 
so  as  to  avoid  combat. 

b.  Surrender. 

c.  Attempt  to  hide.  Consider  a  scout  or  small  reconnaissance  patrol  with  intent  on  gaining 
information  on  an  enemy's  activities.  The  scout  or  patrol  attempts  to  avoid  detection  by 
moving  more  slowly,  concealing  its-self,  and  adopting  an  appropriate  weapons  control 
order.  If  these  attempts  are  communicated  in  the  appropriate  attributes,  then  it  would 
seem  appropriate  to  allow  the  opposing  forces  to  operate  in  close  proximity  with  each 
other  without  engaging  in  combat.  It  would  also  seem  appropriate  to  periodically  assess 
whether  the  reconnaissance  element  has  been  discovered  and  if  so,  then  again  initiate 
the  NETN_OfferService  interaction  to  start  ground  combat. 

2.  Both  of  the  federates  refuse  the  NETN_OfferService  interaction.  The  same  three  options  are 
available  to  both  federates. 

Variations: 

•  CASF  is  itself  one  of  the  federates  which  owns  an  object(s)  that  is  part  of  the  combat 
adjudication.  CASF  initiates  the  NETN_OfferService  interaction  as  before  and  adjudicates  the 
combat  if  accepted  by  the  other  federate.  This  variation  is  problematic  only  insofar  as  the 
conflict  resolution  is  thought  to  be  unfair.  Recommend  an  initial  implementation  consistent  with 
(the  same  as)  CASF  acting  as  a  service  for  other  federates  and  resolving  issues  if  and  when  they 
arise.  The  alternative  is  dedicating  a  federate  to  conflict  adjudication  which  would  certainly  be 
more  expensive  and  might  preclude  using  that  federate  for  other  federation  functionality  (if  for 
some  reason  more  than  one  instance  of  the  federate  is  not  supportable). 

9.6.2  Area-effects  Munitions 

Area-effects  munitions,  whether  fired  by  indirect-fire  weapons  systems  or  dropped  by  air,  are  typically 
modeled  as  discrete  munitions  and  thus  may  be  handled  with  the  existing  RPR  FOM  WeaponFire  and 
MunitionDetonation  interactions  with  the  following  caveats.  Federation  agreements  are  proposed  to 
decrease  the  number  of  interactions  sent  as  follows: 

•  For  area-effects  munitions  fired  in  support  of  Aggregate  vs.  Aggregate  combat,  WeaponFire  and 
MunitionDetonation  interactions  will  NOT  be  used.  Instead,  the  firing  unit(s)  will  be  included  as 
supporting  units  as  discussed  in  CASF  section  above. 

•  For  artillery  missions  NOT  fired  in  support  of  Ground-to-Ground  Combat,  the 
MunitionDetonation  interaction  will  be  used  with  the  QuantityFired  parameter  sent  to  the 
number  of  rounds  in  the  volley,  e.g.  for  a  battalion  of  18  howitzers  firing  a  battalion  10,  we  would 
expect  ten  interactions  each  with  QuantityFired  equal  to  eighteen. 

For  air-delivered  "dumb  bombs,"  the  QuantityFired  parameter  will  be  sent  to  the  number  of 
simultaneously  delivered  bombs. 


Note  that  in  the  cases  above  referencing  use  of  the  RPR  FOM  WeaponFire  and  MunitionDetonation 
interactions,  we  will  use  the  convention  that  both  interactions  are  necessary  only  if  the  munition  will  be 


instantiated  as  a  BaseEntity  object,  otherwise  the  firing  federate  need  only  initiate  the 
MunitionDetonation  interaction. 

9. 7  In  ter  action  Extensions 
9.7.1  NETN_CombatResult 

The  NETN_CombatResult  is  a  subclass  of  NETN_Service  and  is  initiated  by  CASF  to  communicate 
engagement  results.  CASF  will  usually  send  at  least  two  interactions;  one  to  each  of  the  participating 
federates  though  for  protracted  engagements,  CASF  may  send  periodic  interactions  providing 
incremental  engagement  results.  In  all  cases,  the  interaction  consists  of  personnel,  equipment,  and 
supply  status  changes  as  a  result  of  the  engagement.  Inherited  attributes  are  shown  in  italics. 


Parameters 

Data  Type 

Default  value 
(if  optional) 

Definition 

ServicelD 

EventldentifierStruct 

(NotOptionol) 

Unique  identifier  for  a  service 

Consumer 

NETN UniquelD 

(NotOptionol) 

Entity  that  has  requested  the  service 

Provider 

NETN_UniquelD 

(NotOptionol) 

Providing  or  intended  provider 
entity 

EngagementResults 

EngagementResultsList 

Struct 

0 

The  list  of  unique  IDs  damaged  in 
the  engagement  together  with  their 
associated  damage. 

SuppliesConsumed 

SupplyStructArrayl 

0 

The  supplies  consumed  during 
the  engagement. 

9.7.2  EngagementResultListStruct 

An  array  of  elements  of  Datatype  EngagementResultStruct  with  cardinality  0+. 


9.7.3  EngagementResultStruct 


Name 

Type 

Semantics 

UniquelD 

NETN_UniquelD 

The  unique  identifying  alphanumeric  code  of  the 
referenced  object. 

DamageState 

DamageStatusEnhancedEnum32 

The  damage  state  of  the  referenced  object. 

9.7.4  SupplyStructArrayl 

An  array  of  elements  of  Datatype  SupplyStruct  with  cardinality  0+. 


9.7.5  SupplyStruct 


Name 

Type 

Semantics 

The  type  of  supply  (as  described  in  the  Bit  Encoded 

SupplyType 

EntityTypeStruct 

Values  for  Use  with  Protocols  for  Distributed  Interactive  Simulation 
Applications) 

The  number  of  units  of  the  supply  type.  The  unit  measure  depends  on 

Quantity 

Float4 

the  supply  type  and  shall  use  the  SI  units  of  measurement  used  for  such 
supplies. 

9.7.6  NETN_MunitionDetonation 

The  NETN_MunitionDetonation,  extends  the  existing  RPR  FOM  interaction  to  enable  Entity  versus  Aggregate 
combat  engagements,  that  is,  an  Entity  firing  individual  munitions  against  a  unit  comprised  of  equipment 
vulnerable  to  that  munitions  type.  The  extension  is  necessary  to  distinguish  between  the  different  equipment  types 
in  the  aggregate  which  may  be  vulnerable  to  the  munitions.  For  example,  an  attack  helicopter  armed  with  AGM- 


114  Hellfire  missiles  attacking  a  mechanized  task  force  would  logically  fire  at  tanks  first,  then  infantry  fighting 
vehicles,  then  trucks.  Including  the  preferred  target  list  in  the  munitions  detonation  allows  communication  of  the 
tactical  intent.  If  possible,  the  receiving  federate  should  adjudicate  the  munitions  effects  against  the  first  entity 
type  on  the  list  closest  to  the  DetonationLocation  of  the  munition. 


Parameters 

Data  Type 

Semantics 

UniquelD 

NETN_UniquelD 

The  unique  identifying  alphanumeric  code  of  the  aggregate 
for  electronic  transmissions. 

PreferredTargetList 

EntityTypeStructArray 

A  prioritized  list  of  target  types 
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2  Definitions  and  Abbreviations 


ACT 

ASTi 

CFBLNet 

CLR 

CRC 

CWE 

DIS 

DNS 

DWG 

FAD 

FTP 

Gbit/s 

HLA 

IP 

IWG 

JCATS 

JFTC 

JTLS 

JWC 

LAN 

LVC 

Mbit/s 

MSG 

MSAB 

NATO 

NC3A 

NETN 

NMSG 

NRF 

NTP 

NWG 

PoP 

POP3 

QoS 

RTI 

SENECA 

Allied  Command  Transformation 

Advanced  Simulation  Technology,  inc. 

Combined  Federated  Battle  Laboratories  Network 

CFBLNet  Lead  Representative 

Central  RTI  Component  (HLA) 

Collaborative  Work  Environment 

Distributed  Interactive  Simulation 

Domain  Name  System 

Documentation  Workgroup 

Federation  Agreements  Document 

File  Transfer  Protocol 

Giga  bit  per  second 

High  Level  Architecture 

Internet  Protocol 

Initiative  Workgroup 

Joint  Conflict  and  Tactical  Simulation 

Joint  Forces  Training  Command 

Joint  Theatre  Level  Simulation 

Joint  Warfare  Centre 

Local  Area  Network 

Live,  Virtual,  Constructive 

Mega  bit  per  second 

(NATO)  Modelling  &  Simulation  Group 

Multinational  Security  Accreditation  Board 

North  Atlantic  Treaty  Organization 

NATO  Command  &  Control  and  Consultation  Agency 

NATO  Education  and  Training  Network 

NATO  Modelling  &  Simulation  Group 

NATO  Response  Force 

Network  Time  Protocol 

Network  Workgroup 

Point  of  Presence 

Post  Office  Protocol  version  3 

Quality  of  Service 

Run  Time  Interface  (HLA) 

Simulation  Environment  for  Network-Enabled  Capability  Assessment 
(Dutch  national  NEC  network) 

SMTP 

SNMP 

STANAG 

SWG 

TG 

VoIP 

VTC 

WAN 

Simple  Mail  Transfer  Protocol 

Simple  Network  Management  Protocol 

Standard  NATO  Agreement 

Security  workgroup 

Task  Group 

Voice  over  Internet  Protocol 

Video  Tele  Conference 

Wide  Area  Network 
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This  document  is  the  deliverable  of  the  MSG-068  NETN  Infrastructure  Working  group 
and  provides  the  infrastructure  design  and  recommendations  for  implementation. 


2.1.1  NETN  usage 

NETN  connectivity  should  be  flexible  in  the  sense  that  nations  and  organisations  that 
have  access  to  the  NETN  infrastructure  will  be  able  to  perform  exercises  or  experiments 
in  different  configurations.  In  some  cases  all  nations  may  want  to  join  a  specific  event,  in 
other  cases,  a  (small)  numbers  of  nations  may  use  NETN  for  a  particular  training 
exercise  or  mission  preparation  event. 

NETN  is  intended  to  become  a  permanent  (persistent)  NATO  capability.  The  preparation 
time  to  set  up  a  particular  event  should  be  minimised  as  a  result  of  the  permanent 
character  of  NETN.  As  NETN  consists  of  four  projects  the  initial  and  full  operational 
capability  will  be  implemented  in  phases  according  to  the  project  plans.  Testing  and 
incremental  implementation/upgrading  is  expected  to  take  several  years.  Additional  sites 
and  new  applications  will  be  added  during  these  years. 

2.1.2  NETN  nations  involved 

The  following  nations  and  organisations  were  initially  involved  in  NETN  when  planning 
was  started  for  the  infrastructure  design. 


Table  1  nations  and  organisations  originally  involved 


Country 

NATO  Country  Code 

Number  of  sites 

Australia 

AUS 

? 

Bulgaria 

BGR 

? 

Czech  Republic 

CZE 

? 

France 

FRA 

3 

Germany 

DEU 

3 

Italy 

ITA 

? 

NATO 

NATO 

1 

Netherlands 

NLD 

1 

Romania 

ROU 

? 

Slovenia 

SVN 

? 

Spain 

SPA 

1 

Sweden 

SWE 

? 

Turkey 

TUR 

? 

United  Kingdom 

GBR 

? 

United  States 

USA 

? 

Note:  in  the  final  experiments  of  NETN  (2010)  several  nations  moved  their  assets  to 
other  sites  and  participated  from  that  location. 

2.2  Applications  and  information  flow 
The  following  applications  are  foreseen  in  NETN: 

•  Simulators  (including  simulated  radio  and  data  links),  possibly  with  hardware  in 
the  loop  for  training  purposes.  Simulation  interoperability  will  be  based  on  the 
High  Level  Architecture  (HLA)  IEEE  1516  as  agreed  by  STANAG  4603. 

•  C2  systems,  mainly  identical  to  the  applications  that  are  used  operationally 
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•  Video  Tele  Conferencing  (VTC)  for  exercise  mission  briefings,  mission  planning 
and  after  action  review. 

•  Video  Tele  Conferencing  (VTC)  for  technical  briefings,  technical  planning  and 
technical  after  action  review. 

•  VoIP  for  technical  management  and  control  (before,  during  and  after  the 
exercise) 

•  Network  remote  management,  control  and  monitoring 

•  Network  Time  synchronisation  (using  Network  Time  Protocol  NTP) 

Also  classified  data  storage  and  data  exchange  for  planning,  results,  documentation  etc 
should  be  accessible  from  all  sites.  This  includes: 

•  E-mail 

•  Webservers,  WIKI  based  collaborative  workspaces 

•  FTP  servers  (e.g.  to  distribute  scenario  data) 

All  mandatory  applications  should  be  available  at  all  sites. 


Table  2  Applications 


Application 

Protocols 

Remarks 

VoIP 

Mandatory 

Simulation 

Mandatory 

HLA  IEEE  1516  (according  to  STANAG  4603)  using  a 
FOM  based  on  the  NETN  reference  FOM  which  is 
based  on  RPR-FOM  2d17. 

Note:  legacy  systems  using  DIS  or  HLA  1.3  need 
adapters/bridges/gateways. 

C2,  Datalinks 

Mandatory 

HLA  IEEE  1516  (according  to  STANAG  4603)  using  a 
FOM  based  on  the  NETN  reference  FOM  which  is 
based  on  the  HLA  Link  16  BOM  (SISO-STD-002- 
2006). 

Note:  legacy  systems  using  SIMPLE,  MTDS,  or  NACT 
need  adapters/bridges/gateways. 

Radio  Simulation 

Mandatory 

HLA  IEEE  1516  (according  to  STANAG  4603)  using  a 
FOM  based  on  the  NETN  reference  FOM  which  is 
based  on  RPR-FOM  2d17. 

Notably  ASTi  systems 

VTC 

Mandatory 

Storage 

Mandatory 

2.2.1  Information  flow  between  applications 

The  proposed  solution  from  a  user  perspective  should  be  to  provide  a  number  of 
physically  separated  networks  that  are  dedicated  to  a  certain  type  of  information  flow. 
For  example  a  network  dedicated  to  (HLA  based)  simulation  data,  another  network 
intended  for  C2  related  data  and  networks  reserved  for  VoIP,  VTC  etc.  The  functionally 
separated  networks  would  in  fact  be  logical  channels  that  all  share  the  same  network 
infrastructure  on  the  WAN  between  nations  or  sites.  Network  configuration  control  would 
allow  a  flexible  allocation  of  WAN  bandwidth  to  specific  data  channels.  This  method 
would  provide  maximum  bandwidth  to  the  simulation  channel  during  an  exercise,  while 
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reallocating  this  WAN  bandwidth  to  VTC  channels  during  Briefings  and  Debriefing 
sessions. 


National 

Point  Of  Presence 


Figure  1  Assigning  WAN  bandwidth  to  logical  channels 

2.2.2  Information  flow  between  sites 

It  should  be  possible  that  all  mandatory  applications  can  function  on  all  sites  involved  in 
a  particular  NETN  event.  The  network  should  be  ‘fully  meshed’  and  suitable  for  classified 
data  exchange  among  all  sites. 

2.2.3  Bandwidth 

Several  applications  require  significant  bandwidth.  However,  the  required  bandwidth 
depends  on  the  training  scenarios  and  the  applications  that  are  in  use  for  the  scenario. 

In  most  cases,  not  all  of  the  applications  listed  above  will  be  operational  at  the  same 
time  (e.g.  VTC  and  Simulations).  The  NETN  infrastructure  should  allow  a  flexible 
allocation  of  the  available  WAN  bandwidth  to  different  applications  depending  on  the 
needs.  The  WAN  bandwidth  capacity  should  be  scalable  and  upgrades  or  downgrades 
should  be  relatively  painless. 

2.2.4  Delay  (latency)  and  jitter 

Several  applications  are  time  critical  therefore  the  delay  or  latency  and  especially  jitter 
should  be  kept  at  as  low  as  possible.  Typical  maximum  acceptable  latency  values  for 
real-time  (man-in-the-loop)  simulations  are  100ms  between  any  two  applications.  The 
performance  levels  should  be  guaranteed  to  a  defined  minimum  or  maximum,  thus 
providing  a  certain  Quality  of  Service  (QoS). 

2.2.5  Availability  and  Reliability 

The  NETN  is  intended  for  training  purposes.  It  should  be  available  and  reliable  for 
continuous  periods  of  several  sequential  days.  The  mean  downtime  should  be  minimal 
and  downtime  due  to  maintenance  etc  should  be  planned  in  advance  and  needs  to  be 
scheduled  in  agreement  with  the  user  community. 

2.2.6  Security 

NETN  should  be  able  to  handle  SECRET  data.  Nations  or  organisations  that  are  not 
involved  in  a  particular  event  taking  place  on  the  NETN  infrastructure  should  not  have 
access  to  the  data  related  to  that  event. 
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3  National  Defense  network  infrastructure  overview 

Nations  and  Organisations  often  use  an  isolated  part  of  their  national  defense  network 
infrastructure  to  form  distributed  education  and  training  capability  able  to  support 
training.  The  isolation  is  primarily  required  to  avoid  disruption  of  operational  systems  and 
capabilities  and  provide  a  controlled  sandbox  for  the  distributed  education  and  training 
capability.  This  paragraph  visualise  the  main  characteristics'  from  the  national  and 
organisational  network  in  support  of  Allied  and  Coalition  Education,  Training,  and  /or 
Research  and  Development  within  nations/organisation. 

This  chapter  provides  an  overview  of  several  national  networks  as  identified  by  the 
national  experts  of  the  MSG-068  Network  Infrastructure  subgroup. 


3.1.1  National  and  Organisational  Network  Infrastructures 

3. 1.1.1  Australia 

Defence  Wide  Area  Communications  Network  (DWACN).  Externally  the  Combined 
Federated  Battle  Lab  (CFBL)  network  has  also  been  used  for  international  DSTO 
networking  exercises. 

3. 1.1. 2  Bulgaria 

3. 1.1. 3  Czech  Republic 

3. 1.1. 4  France 

EXAC  C3R  Secure  Network  for  Experiment  and  Referentiel  d’lnteroperabilite 
Technique  (RIT).  The  Celar,  Bruz  element  of  EXAC  C3R  is  also  the  France  PoP  in  the 
Combined  Federated  Battle  Laboratories  Network  (CFBLNet),  enabling  connection  to 
this  Multi-National  Network. 

3. 1.1. 5  Germany 

German  Experimental  Network  which  is  a  VPN  based  network  over  the  German 
Defense  WANBw  (WAN  Bundeswehr)  and/or  Digitales  Ubertragungs  Net 
Bundeswehr.  The  German  Experimental  Network  could  also  use  public  infrastructure 
with  VPN  technology.  The  main  Point  of  Presence  of  the  German  Experimental 
Network  Euskirchen,  is  also  the  German  PoP  in  the  Combined  Federated  Battle 
Laboratories  Network  (CFBLNet),  enabling  connection  to  this  Multi-National  Network. 

3. 1.1. 6  NATO 

3.1 .1 .6.1  NATO  General  Communications  System  (NGCS)  is  the  basic  communications 
infrastructure  for  all  NATO  communications.  It  addresses  voice  and  data  transmission 
requirements,  circuit-switched  and  packet-switched,  for  both  unclassified  and 
classified  (up  to  NATO  SECRET)  communications.  NGCS  connectivity  ranges  from 
Norway  to  Greece  and  from  Norfolk,  Virginia  in  the  US  to  Kabul  in  Afghanistan 
including  all  NATO  Commands  and  Primary  facilities  plus  most  of  the  NATO  nations 
MOD.  The  operation  and  maintenance  of  NGCS  is  the  responsibility  of  the  NATO  CIS 
Services  Agency  (NCSA).  On  request  NGCS  can  support  Exercises  and  Training 
capacity  for  and  between  NATO  Commands  and  facilities. 

3.1 .1 .6.2  NATO  Combined  Federated  Battle  Laboratories  Network  (CFBLNet)  provides  the  NATO 
and  European  main  Point  of  Presence  for  NATO  organisations,  NATO  nations  and 
mission  partners.  High  speed  Wide  Area  Network  links  are  used  to  interconnect  the 
CFBLNet  participants. NATO  Facilities  typically  utlises  the  NGCS  network  (prefered)  or 
dedicated  leased  lines  to  connect  to  the  NATO  CFBLNet  PoP  located  in  NATO  C3 
Agency  ,The  Hague,  Netherlands. 

3. 1.1. 7  The  Netherlands 

The  Netherlands  uses  a  CFBLNet  extension  for  all  experiments  to  connect  military 
sites  inside  the  Netherlands  with  each  other  and  also  to  other  countries  through 
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CFBLNet.  This  network  is  called  SENECA/CFBLNet  and  is  a  1  Gbit/s  Virtual  Private 
Network  (VPN)  special  created  for  this  purpose  on  top  of  a  10  Gbit/s  MOD  network 
and  is  available  on  almost  all  MOD  sites.  At  this  time  8  sites  are  connected  and  this 
could  become  more  in  the  near  future.  SENECA/CFBLNet  is  connected  to  the  NATO 
CFBL  PoP  at  NC3A  in  The  Hague  through  the  NLD-PoP.  Several  security  enclaves 
are  available  on  top  of  this  SENECA/CFBLNet. 

3. 1.1. 8  Romania 

3. 1.1. 9  Slovania 

3.1.1.10  Spain 

There  are  several  sites  in  Spain  involved  in  coalition  experimentation. 

3.1.1.11  Sweden 

The  Point  of  Presence  of  the  Sweden  armed  forces  Enkoping,  is  also  the  Swedish 
PoP  in  the  Combined  Federated  Battle  Laboratories  Network  (CFBLNet),  enabling 
connection  to  this  Multi-National  Network. 

3.1.1.12  Turkey 

3.1.1.13  United  Kingdom 

The  UK  Joint  Multi-National  Information  Assurance  Network  (JMNIAN)  is  a  project 
managed  by  the  Integration  Authority’s  (IA)  Defence  Test  and  Reference  Co¬ 
ordination  Office  (DT&R  CO).  It  provides  a  secure  Asynchronous  Transfer  Mode 
(ATM)  Wide  Area  Network  (WAN)  that  will  connect  Test  &  Reference  sites.  Points  of 
Presence  (PoPs)  at  test  sites  provide  connectivity  to  the  WAN.  The  JCMB  ARTD 
element  of  JMNIAN  is  also  the  UK  PoP  in  the  Combined  Federated  Battle  Laboratories 
Network  (CFBLNet),  enabling  connection  to  this  Multi-National  network.  Key  features 
of  JMNIAN  are:  It  has  a  high  bandwidth,  and  can  operate  in  near  real-time;  It  supports 
a  variety  of  standards/protocols,  such  as  Serial,  ISDN  and  IP;  It  will  be  accredited  to 
SECRET. 

3.1.1.14  United  States 

3.1.1.14.1  Defense  Information  Systems  Network  (DISN) 

DISN  as  DOD’s  networking  capability  for  the  transfer  of  information  in  support  of 
military  operation  in  the  context  of  the  Global  Information  Grid  (GIG).  It  further 
specifies  that  DISN  shall  be  the  means  for  wide-area  and  metropolitan-area 
networking. 

3.1 .1 .14.2  Joint  Training  and  Experimentation  Network  (JTEN) 

JTEN  is  the  communications  network  for  the  Joint  National  Training  Capability 
(JNTC).  U.S.  Joint  Forces  Command  (USJFCOM).  This  network  will  be 
interconnected  with  CFBLNet  July2009  in  support  of  Coalition  JTEN  Initiatives. 

3.1 .1 .14.3  Combined  Federated  Battle  Labs  Network  (CFBLNet)  environment  which  utilizes  a 
distributed  Wide  Area  Network  (WAN)  as  the  vehicle  to  experiment  with  new 
capabilities  by  conducting  Research  and  Development,  Trials  and  Assessment 
including  Training  initiatives.  The  U.S.  CFBLNet  infrastructure  is  extensive  and 
reaches  to  international  demarcation  points  for  the  Southern  Hemisphere  and  Europe. 
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4  Selection  of  Network  Infrastructure  for  NETN 

4. 1  International  Network  infrastructure  overview 

This  chapter  looks  into  network  solutions  for  the  international  infrastructure  which  were 
identified  by  the  experts  of  the  MSG-068  Network  Infrastructure  subgroup. 

4.1.1  CFBLNet 


Figure  2  CFBLNet  logo 


The  Combined  Federated  Battle  Laboratories  Network  (CFBLNet)  is  a  network  build, 
maintained  and  constantly  improved  by  its  members.  The  network  is  available  for 
experiments  and  training  with  different  classifications  and  markings.  Several  nations  and 
NATO  organizations  have  permanent  connections  to  CFBLNet,  while  others  establish  a 
connection  when  needed.  CFBLNet  is  more  than  a  network,  It  features  standard 
services  like,  Network  management,  Crypto  management,  DNS,  Web,  E-Mail,  Voice, 
FTP,  Network  Time  server  and  VTC(on  request).  CFBLNet  has  an  efficient  organisation, 
proven  processes  and  documents  and  includes  a  CFBLNet  secretariat  to  assist  the 
users  in  its  optimum  use  of  the  CFBLNet  capabilities.  It  has  extensive  knowledge  on 
coalition  classified  networks,  security  accreditation  and  rules,  crypto  technology  and 
interactions  between  simulators  and  network  protocols.  The  use  of  CFBLNet  for  NETN 
may  at  first  glance  look  expensive,  but  the  countries  already  connected  to  CFBLNet  use 
the  network  and  organisation  for  multiple  initiatives.  A  new  initiative  like  NETN  should 
consider  that  the  fixed  costs  are  already  paid  for.  CFBLNet  allows  using  various  WAN 
links,  including  leased  lines,  SatCom,  NGCS,  (and  tunnelling  using  the  internet  (with 
special  measures)).  CFBLNet  is  a  closed  network.  CFBLNet  provides  you  an 
established,  stable  international  network  with  proven  information  assurance  measures, 
and  the  support  of  a  robust  environment.  This  results  in  a  sustainable  and  accreditable 
architecture  to  effectively  field  equipment  and  services. 

CFBLNet  has  been  used  to  minimize  risk  in  systems  prior  to  deployment  to  the  war 
fighter;  reducing  costs  and  countless  hours  of  development.  CFBLNet  has  an  effective 
method  for  integrating  and  improving  interoperability  with  allied  and  coalition  partners. 
CFBLNet  has  hosted  many  multi-national  C4ISR  events  and  has  a  track  record  of 
success  that  speaks  for  itself: 

-  CWID 

-  Fleet  Synthetic  Training-Joint 

-  Multi-National  Experiment 

-  Empire  Challenge 

-  Blue  Force  Tracker 

-  NATO  ALTBMD 
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The  CFBLNet  has  supported  several  key  warfighting  Initiatives,  including:  multi-national 
connectivity  for  air  picture;  messaging  services;  collaboration;  multi-level  security 
Initiatives;  homeland  defense  and  crisis  response  tools;  ship-to-ship  command  and 
control;  unmanned  aerial  vehicle  imagery;  and  situational  awareness  via  enhanced 
tactical  data  link  interoperability.  Imagery  and  video  systems  proven  on  CFBLNet  are 
currently  supporting  operations  in  Afghanistan  and  Iraq.  The  network  also  supported  key 
second-tier  warfighting  objectives  including  on-line  distributed  war  gaming  and 
multinational  training  exercises.  Some  specific  success  stories  include  the  following: 

•  Intelligence,  Reconnaissance  and  Surveillance  (ISR)  lessons  learned  in  live  and 
unmanned  aircraft  and  satellite  surveillance  in  Empire  Challenge  06  were  applied 
immediately  in  support  of  International  Security  Assistance  Force  (ISAF)  - 
Afghanistan. 

•  In  Project  Churchill,  the  US-UK  bilateral  trials  led  to  enhanced  communications 
capabilities  for  Unmanned  Combat  Air  Systems. 

•  The  United  Kingdom  International  Support  Team  (UK-IST  III)  and  the  US 
conducted  experiments  that  established  real  time  wargaming  for  C2, 
consultation,  and  future  consequence  mitigation. 

•  NATO  is  very  successfully  using  CFBLNet  for  the  NATO  ALTBMD  program, 
where  CFBLNet  interconnect  all  involved  ALTBMD  sites  and  support  HLA/DIS, 
link,  voice,  VTC  and  other  traffic  to  the  network  distributed  systems,  including 
hardware  in  the  loop  (HWIL)  within  the  involved  nations. 


4.1.2  NGCS 

NATO  General  Communications  System  (NGCS)  is  the  basic  communications 
infrastructure  for  all  NATO  communications.  It  addresses  voice  and  data  transmission 
requirements,  circuit-switched  and  packet-switched,  for  both  unclassified  and  classified 
(up  to  NATO  SECRET)  communications.  NGCS  connectivity  ranges  from  Norway  to 
Greece  and  from  Norfolk,  Virginia  in  the  US  to  Kabul  in  Afghanistan  including  all  NATO 
Commands  and  Primary  facilities  plus  most  of  the  NATO  nations  MOD.  The  operation 
and  maintenance  of  NGCS  is  the  responsibility  of  the  NATO  CIS  Services  Agency 
(NCSA).  On  request  NGCS  can  support  Exercises  and  Training  capacity  for  and 
between  NATO  Commands  and  facilities. 

NGCS  is  evolving  their  capabilities  to  the  NATO  Network  Enabled  Capability  Network 
and  Network  and  Information  Systems  Infrastructure  (NNEC-NII)  which  is  based  on  the 
NCGS  Protected  Core  Network  (P-Core),  an  MPLS  Transport  backbone  with  Traffic 
Engineering  extension.  The  evolving  capability,  expected  to  be  fully  available  2012/2013 
will  support  the  coloured  cloud  principle  on  top  of  the  transport  network.  The  main 
Coloured  clouds  will  be  NS,  NU/NR  and  MS.  In  support  of  specific  requirements  or  for 
training,  exercises  and  events,  VPN  can  be  provisioned  with  the  main  clouds  (equal 
classification/releasability)  or  separate  Coloured  clouds  can  be  provisioned  for  other 
classification/releasability  or  specific  requirements.  For  these  separated  Coloured  clouds 
the  management  aspects  needs  to  be  taken  into  account. 

The  NGCS  Transport  and  Coloured  clouds  fully  support  Quality  of  Service  (QoS),  are 
Service  Level  Managed  with  SLA’s  from  a  NGCS  Services  catalogue  providing  SLA 
templates. 
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The  NGCS  P-Core  going  to  be  coupled  with  the  national  defense  networks  with  the  use 
of  Packet  Network  gateways  capability.  Initial  on  L2  level  best  effort  (phase  I:  2010), 
later  also  on  Layer  3. 

Topic  of  attention: 

o  Accreditation  is  required  for  applications. 

o  Restrictions  and  issues  connecting  simulations  and  operational  systems 
o  Intended  for  use  between  NATO  sites  rather  than  national  assets. 


4.1.3  BICES 


Figure  3  BICES  logo 


Battlefield  Information  Collection  and  Exploitation  Systems  (BICES)  is  an  operational 
NATO  network.  The  objective  of  BICES  is  to  share  and  exchange  information  / 
intelligence  among  the  participating  Nations  and  with  NATO  in  peace,  crisis  and  war 
through  the  use  of  interoperable  Automatic  Data  Processing  (ADP)  based  national  and 
NATO  intelligence  support  systems.  BICES  is  a  network  reserved  for  operations  and  not 
for  experiments  or  training.  This  implies  that  applications  and  systems  need 
accreditation  before  they  can  be  used  on  BICES.  BICES  is  not  available  on  many  sites 
that  were  listed  for  NETN. 

4.1.4  GEANT 

*  - _ _ 

f  ’  W  Ak  NfT® 

Figure  4  GEANT  logo 

GEANT  provides  low  latency  and  high  throughputs,  which  makes  it  suitable  for 
distributed  test  beds  with  unclassified  and  near  real-time  requirements.  GEANT  is  the 
interconnecting  network  to  the  national  academic  research  networks  like  for  instance 
SurfNET  in  the  Netherlands.  However,  several  issues  have  been  identified  in  GEANT: 

o  There  is  not  always  a  guaranteed  bandwidth,  latency  or  Quality  of  Service 
available. 

o  Many  countries  do  not  allow  SECRET  networks  operating  over  open  networks  or 
networks  connecting  the  internet.  GEANT  has  interconnections  to  internet, 
o  GEANT  and  its  national  networks  are  an  academic  research  network  and  is  not 
available  on  military  sites  (only  research  institutes  and  universities) 
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4.1.5  Public  Internet 

The  public  Internet  is  readily  available  at  almost  any  location  on  earth.  The  connection 
costs  are  in  general  very  low.  The  issues  regarding  the  use  of  the  public  Internet  for 
NETN  are: 

o  There  is  no  guaranteed  bandwidth,  latency  or  Quality  of  Service  available. 
Contracts  with  Internet  Service  Providers  (ISPs)  do  not  in  general  provide  solid 
performance  guarantees. 

o  Many  countries  do  not  allow  SECRET  networks  operating  over  open  networks  or 
networks  connecting  to  the  internet. 

Remarks:  USA  and  UK  have  stated  that  classified  simulation  assets  are  not  allowed  to 
have  connections  to  open  internet.  The  Open  Internet  and  VPNs  have  been  used  for 
several  experiments  (e.g.  FMV  SmartLab  Sweden). 

4.1.6  Proprietary  networks  on  leased  lines 

Proprietary  networks  on  leased  telecom  lines  can  be  made  available  at  almost  any 
location  on  earth.  The  connection  costs  are  in  general  significant.  The  issues  regarding 
the  use  of  proprietary  networks  for  NETN  are: 

o  Guaranteed  bandwidth,  latency  and  Quality  of  Service  are  in  general  available  at 
a  price. 

o  A  management  organisation  needs  to  be  in  place  to  negotiate  contracts  with 
telecom  operators  and  deal  with  technical  issues  and  maintenance. 
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4.2  International  Network  infrastructure  selection 

The  table  below  compares  the  international  network  solutions  for  NETN  which  were 
presented  above. 


Table  3  Network  comparison 


CFBLNet 

BICES 

NGCS 

(current) 

NGCS 

(NNEC-NII) 

GEANT 

Internet 

Leased 

lines 

Network  physical 
available 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

Network 
available  to  all 
NETN 
participants 

YES 

NO 

YES1 

YES 

YES 

(through 

internet) 

YES 

YES 

Allowed  to  carry 
SECRET 
information  by 
national  security 
rules 

YES 

YES 

YES 

YES 

NO 

NO 

YES  with 
additional 
security 
measure 

s 

Organisation 
has  knowledge 
of  classified 
networks 

YES 

YES 

YES 

YES 

NO 

NO 

NO 

Ownership 

All  MODS 
connected 

NATO 

NATO 

NATO+ 

MOD 

connected 

ISPs 

Telecom 

operator 

Black  Network 
management 

Available 

Available 

Available 

Available 

Not 

available 

Not 

available 

Not 

available 

Security 
organisation  in 
place 

YES 

YES 

YES 

YES 

NO 

NO 

NO 

Security 
measures  and 
procedures  in 
place 

YES 

YES 

YES 

YES 

NO 

NO 

NO 

Given  the  NETN  requirements  and  the  comparison  of  the  available  infrastructure 
options,  the  MSG-068  Infrastructure  Working  group  has  decided  to  base  the  design  of 
the  network  infrastructure  on  the  Combined  Federated  Battle  Laboratory  (CFBL) 
Network.  CFBLNet  will  be  the  black  (unclassified)  backbone  between  participating 
nations  and  NATO  organisations.  The  next  chapters  will  discuss  the  infrastructure 
design  in  more  detail. 


1  Network  available  to  all  NATO  nations.  To  non-NATO  nations  through  specific  separate  domain 
build  or  using  Information  Exchange  gateways. 
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5  Combined  Federated  Battle  Laboratories  Network  (CFBLNet) 

The  Combined  Federated  Battle  Laboratories  Network  (CFBLNet)  is  a  network  build, 
maintained  and  constantly  improved  by  its  members.  The  network  is  available  for 
experiments  and  training  with  different  classifications  and  markings.  Several  nations  and 
NATO  organizations  have  permanent  connections  to  CFBLNet  while  others  establish  a 
connection  when  needed. 

USA  BEL 


Figure  1  CFBLNet  countries, 

NATO  nations  and  Partners  perspective  (January  2009) 


5. 1  History 

In  April  1999,  the  US  made  a  proposal  to  the  NATO  C3  Board  to  establish  a  Combined 
Federated  Battle  Laboratories  Network  (CFBLNet).  The  Concept  was  to  build  on  the 
Combined  Wide  Area  Network  (CWAN)  that  had  been  established  each  year  for  JWID, 
to  establish  a  year-round  network  for  research,  development,  trials,  and  assessment 
operating  at  a  Combined  Secret  Releasable  accreditation  level. 

The  participants  would  include  the  US,  the  Combined  Communications-Electronics 
Board  (CCEB),  and  NATO.  NATO  in  the  CFBLNet  context,  are  all  individual  NATO 
nations  and  NATO  the  organisation.  The  Network  would  be  used  to  develop  coalition 
interoperability,  doctrine,  procedures  and  protocols  that  can  be  transitioned  to 
operational  coalition  networks  in  future  contingencies. 
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The  CFBLNet  will  leverage  Coalition  Warrior  Interoperability  Demonstration  (CWID), 
formerly  JWID,  resources  and  existing  NATO  and  national  laboratories  and  test  beds.  It 
is  not  a  US  owned  network.  As  a  combined  network,  the  participants  will  have  equal  say 
in  its  utilization  and  management,  yet  specific  initiatives  may  be  configured  between  any 
numbers  of  participants.  The  CFBLNet  participants  are  to  respect  sovereign  and 
intellectual  property  rights  of  activities  conducted  on  the  network. 

5.2  CFBLNet  organisation 

The  CFBLNet  will  fall  under  the  oversight  of  a  CFBLNet  Senior  Steering  Group  (C-SSG), 
comprised  of  three  Flag  level  executives  representing  U.S.,  NATO,  and  CCEB.  Control 
of  the  CFBLNet  will  be  conducted  by  a  CFBLNet  Executive  Group  (C-EG)  of  06  (or 
equivalent)  level  members  also  representing  US,  NATO  and  CCEB,  working  for  the  C- 
SSG  members.  The  C-EG  may  stand  up  subordinate  groups  as  required. 


Major  General  Dennis  Moran  (USA) 
Major  General  Michael  Clifford  (CCEB) 
Mr.  Dag  Wilhalmsen  (NATO) 


Policy/Decision  Authority 
Execution/Coordination 


Organizational  & 
National  Leads 


Senior  Steering  Group  (SSG) 
US  -  CCEB  -  NATO 


Executive  Group  (EG) 
US  -  CCEB  -  NATO 


Secretariat 

(USA:  AITS  JPO) 


Mr.  Steve  Pitcher  (USA) 

CDR  TimNeal-Hopes  (CCEB) 
Mr.  Einar  Thorsen  (NATO) 


Security 
Working  Group 


Network 
Working  Group 


Initiatives 
Working  Group 


Documents 
Working  Group 


Figure  2  CFBLNet  organisation  (2008) 

There  are  several  roles  in  the  CFBLNet  organisation.  These  roles  are: 


•  The  CFBLNet  Lead  Representative  (CLR)  is  responsible  for  coordination  within 
the  CN/O;  Initiatives,  work,  equipment,  crypto,  accreditation,  etc. 

•  The  Networking  Working  Group  (NWG)  is  responsible  for  building  and 
maintenance  the  required  network  and  enclaves. 

•  The  Security  Working  Group  (SWG)  is  responsible  for  the  security  on  the 
network  (PoP)  and  in  the  enclaves. 

•  The  Document  Working  Group  (DWG)  is  responsible  for  correct  documentation 

•  The  Initiative  Working  Group  (IWG)  is  responsible  coordination  of  initiatives 

•  The  national  Multinational  Security  Accreditation  Board  (MSAB)  representative  is 
responsible  for  accreditation  of  the  national  sites  and  initiatives. 

One  of  the  big  advantages  of  this  construction  is  that  several  national  MSAB 
representatives  taking  part  in  the  Security  Working  Group  (SWG)  and  are  at  the  CFBL 
Management  Meetings  each  6  month. 
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5.3  CFBLNet  Architecture  and  Terminology 

CFBLNet  is  a  network  build  and  maintained  by  its  members.  The  network  consists  of 
sites,  national  Point  of  Presence  (PoPs),  infrastructure,  services  and  knowledge 
management.  The  national  /  organisational  PoP  is  the  connection  from  the  national  / 
organisational  Wide  Area  network  (WAN)  to  the  international  part  of  the  CFBL  WAN. 

Backbone  Infrastructure 

The  BLACKBONE  (=  Black  backbone)  provides  a  common,  closed,  unclassified  IP 
routed  network  layer  implementation  using  a  mixture  of  both  ATM  and  IP  bearer 
networks.  Its  primary  purpose  is  to  transport  encrypted  traffic  throughout  the  network. 

Enclaves  are  the  cryptographic  protected  networks  on  top  of  the  CFBLNet  BlackBone. 
Each  enclave  has  a  classification  and  a  marking  indicating  security  level  and  the 
countries  allowed  connecting. 

Initiatives  use  the  Enclaves  to  exchange  data. 

5.3.1  CFBLNet  Levels 

5.3.1 .1  CFBLNet  Level  0  the  international  network 

The  CFBLNet  level  0  network  is  the  network  between  nations  and/or  NATO 
organisations.  There  are  three  regional  PoPs  (Europe,  North  America  and  Oceania) 
connecting  the  nations  /  organisation  PoPs.  The  national  /  organisation  PoPs  connect 
the  nations  /  organisation  sites  to  the  international. 


Figure  5  Level  0  connections  (December  2008) 
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5. 3. 1.2  CFBLNet  Level  1  the  national  network 

The  CFBLNet  level  1  network  is  the  network  between  national  PoPs  and  the  national 
sites.  The  national  PoP’s  network  and  sites  are  maintained  by  national  CFBLNet 
organisation. 


Line  rate 
Capacity 


Figure  6  NLD  example  Level  1  connections  (January  2009) 


5.3.1 .3  Level  2  is  the  site  network 

The  CFBLNet  level  2  network  is  the  network  at  the  national  sites.  The  architecture  differs 

for  almost  all  sites  but  it  consists  at  least  of  a  black  router,  a  crypto  and  a  red  router. 

5.3.2  Enclaves 

There  are  several  security  enclaves  on  CFBLNet. 

•  The  CFBLNet  BLUE  enclave  is  a  permanent  classified  IP  routed  logical  network 
operating  over  the  BLACKBONE.  It  will  operate  as  a  System  High  logical  network 
at  the  SECRET  level,  releasable  to  AUSCANNZUKUS  +  NATO; 

•  The  CFBLNet  RED  enclave  is  also  a  permanent  classified  IP  routed  logical 
network  operating  over  the  BLACKBONE.  It  will  operate  as  a  System  High  logical 
network  at  the  NATO  SECRET  level. 

•  The  CFBLNet  Unclassified  Enclave  (CUE).  The  CUE  is  a  permanent  enclave 
operating  over  the  BLACKBONE. 

•  Temporary  enclaves  are  created  for  a  finite  period  to  support  the  execution  of 
specific  Initiatives  and  operating  over  the  BLACKBONE.  The  level  of 
classification  and  release  caveats  used  within  these  enclaves  will  be  determined 
by  the  Initiative  requirements. 

o  The  CFBLNet  GREEN  enclave  is  a  temporary  classified  IP  routed  logical 
network  operating  over  the  BLACKBONE.  It  will  operate  as  a  System 
High  logical  network  at  the  SECRET  level,  releasable  to 
AUSCANNZUKUS  +  NATO  +  Sweden; 
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5.4  CFBLNet  countries  and  sites  involved 

Currently,  there  are  already  many  sites  connected  to  CFBLNet. 


Nation/Organization 

Number  of  Sites 

Australia  (AUS) 

13 

Canada  (CAN) 

29 

United  Kingdom  (GBR) 

37 

New  Zealand  (NZL) 

6 

Germany  (DEU) 

17 

Spain  (ESP) 

3 

France  (FRA) 

3 

Italy  (ITA) 

8 

NATO 

9 

Netherlands  (NLD) 

8 

Norway  (NOR) 

7 

Poland  (POL) 

1 

Sweden  (SWE) 

1 

USA 

22 

Total 

164 

Figure  7  Connected  sites  to  CFBLNet  (October  2008) 

Detailed  up-to-date  information  regarding  the  countries  and  sites  connectivity  to 
CFBLNet  and  Point  of  Contact  data  is  available  through  the  CFBLNet  organisation. 
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6  NETN  Network  design 
6. 1  Introduction 

The  design  of  the  NETN  infrastructure  is  based  on  the  assumption  that  the  Combined 
Federated  Battle  Laboratory  (CFBL)  Network  will  be  the  black  (unclassified)  backbone 
between  participating  nations.  Each  participating  nation  will,  or  has  already,  acquired  the 
necessary  routers,  switches,  crypto  devices  and  workstations  to  meet  the  respective 
national  requirements  for  installation,  connection  and  operation  of  the  CFBL  network  at 
the  nation’s  respective  sites.  The  NETN  network  design  will  be  used  as  the  basis  for 
future  M&S  applications  as  planned  within  ACTs  NETN  initiative. 

The  MSG-068  Infrastructure  Subgroup  developed  the  initial  network  topology  design  for 
the  Experiments.  Given  the  nature  of  the  experiments  (unclassified,  technical  feasibility 
demonstration)  and  the  available  resources,  the  decision  was  taken  to  establish  the 
NETN  Infrastructure  on  an  existing  CFBLnet  Unclass  Enclave  (CUE),  also  known  as 
White  Enclave  ((future)  Standing  Class  Enclave).  The  necessary  paper  work  (CFBLNet 
Initiative  Information  Package  CIIP)  was  produced  in  collaboration  with  the  nations  and 
the  CFBLnet  organization.  The  proposed  topology  with  planned  bandwidths  is  shown  in 
the  diagram  below.  Note  that  a  permanent  Infrastructure  solution  should  establish  a 
dedicated  NETN  Enclave  under  CFBLNet  to  simplify  and  streamline  the  process  of 
setting  up  an  exercise  or  experiment. 


^  Research  &  Technology  Organisation 

<  >  i"\\  - 


NETN-U  Initiative  on 

CFBL  Net  Unclassified  Standing  Enclave 


CATOD,  Paris 
FRA-xxx 


6.2  Network  concept 

The  idea  is  to  create  a  new  permanent  enclave  for  coalition  purposes.  At  this  moment 
there  are  several  enclaves  on  the  CFBLNet  BlackBone.  The  enclave  suitable  for  this  is 
the  temporary  enclave  CFBLNet  GREEN.  The  enclave  CFBLNet  GREEN  ends  in  the  red 
router.  At  the  red  router  are  several  Virtual  Private  Networks  (VPNs)  available,  all  with 
the  same  releasability.  One  of  the  VPNs  is  NETN.  Each  initiative  has  its  own  end  switch. 
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Initiative  A  Initiative  B 


Initiative  Switch 


Enclave  router 


Approved  crypto 


Black  site  router 


Figure  8  network  level  2 

The  black  router,  crypto  and  enclave  router  are  managed  by  CFBLNet.  The  initiative 
switch  is  managed  by  the  initiative.  This  concept  permits  that  a  NETN  network-manager 
is  able  to  manage  the  NETN  network  within  the  agreed  boundaries.  An  example  is  that 
the  NETN  network-manager  stops  all  Conference  calls  and  adds  all  bandwidth  to  the 
training  simulators  to  prevent  hiccups  in  the  exercise.  After  the  training  session  the  VTC 
is  allowed  to  access  the  NETN  network  for  after  action  review.  There  are  also 
possibilities  to  automate  this  process. 

Another  advantage  of  this  concept  is  that  hardware  and  software  for  services  like  “Voice 
over  IP”  (VoIP),  the  Video  teleconference  manager,  Network  time  server,  and  so  on  can 
be  used  for  multiple  parallel  initiatives  while  the  data  (with  the  same  level  and 
releasability)  itself  is  not  mixed.  This  will  reduce  costs  for  everybody. 

6.2.1  Hardware 

The  proposed  hardware  for  a  new  site  is  mentioned  below. 


Figure  9  Black  site  router  examples 


The  Black  site  router  is  the  CISCO  2851  or  3845  (for  E3  connection)  router.  This  router 
is  power  full  enough  to  handle  the  high  speed  encrypted  data  streams.  (IOS=enterprice) 


Figure  10  Enclave  Crypto 


The  enclave  crypto  is  the  TCE621B  (or  C)  for  Europe  and  the  TACLANE  El  00  for  the 
USA. 
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Figure  11  Enclave  router 


The  enclave  router  is  the  CISCO  3845  or  ASR  1002  router.  This  is  a  powerful  router 
capable  of  handling  multiple  VPNs  and  tunnels. 

The  initiative  switch  has  to  be  divined.  The  switch  should  have  “power  over  Ethernet”  to 
support  IP  phones. 


Figure  12  Default  enclave  IP  phone 


6.3  Security 

Each  national  site  is  responsible  for  the  certification  and  accreditation  of  their  respective 
sites  in  accordance  with  their  national  directives.  Each  nation  is  responsible  for 
submitting  the  site  national  accreditation  endorsement  certificate  (S-NAEC)  and  the 
initiative  national  accreditation  endorsement  certificate  (l-NAEC)  for  each  participating 
site.  The  S-NAEC  is  the  authority  to  connect  to  the  CFBL  network,  while  the  l-NAEC  is 
the  authority  to  operate  and  participate  in  an  approved  CFBL  initiative. 

Each  nation  will  maintain  a  security  posture  in  accordance  with  CFBL  instructions  and 
national  policies. 

The  network  design  is  based  on  a  fully  meshed  red  network  between  the  crypto  devices 
at  all  event  sites  to  prevent  a  single  point  of  failure  causing  connectivity  issues.  Dynamic 
routing  protocols  will  be  utilized  vice  static  routes  whenever  possible. 

Each  nation  is  responsible  for  obtaining  the  proper  crypto  devices.  Network  separation  is 
provided  by  the  different  key-mat  authorized  for  the  different  initiatives. 

6.3.1  Accreditation 

Each  country  is  responsible  for  accreditation  of  its  national  sites.  If  a  site  does  not  have 
a  valid  accreditation  certificate  the  site  should  be  disconnected  from  CFBLNet. 


Unclassified  /  for  official  use  only 


Page  22/40 


Unclassified  /  for  official  use  only 


6.3.2  Classification 

The  classification  of  the  NETN  environment  is  “SECRET” 

6.3.3  Marking 

Because  Sweden  is  not  a  NATO  country  the  marking  is  “releasable  to  NATO  and  SWE”. 
The  strong  recommendation  is  to  include  all  future  CFBLNet  nations  in  this  enclave  to 
avoid  security  and  releasability  issues  in  the  future. 

6.3.4  Crypto 

Event  sites  are  connected  by  a  fully  meshed,  dynamic  protocol  routed  network.  This 
allows  the  exchange  of  routing  information  to  prevent  a  single  point  of  failure  from 
preventing  connectivity  between  all  sites  when  a  site(s)  is  not  operating  properly,  due  to 
accreditation  or  technical  issues. 

The  network  is  protected  by  approved  crypto  and  operates  in  a  "system  high”  concept. 
The  preferred  crypto  is  the  TCE  621b  for  Europe.  NC3A  can  bridge  this  to  a  TACLANE 
for  the  USA. 

6.3.5  Key  material 

The  key  material  for  the  TCE  621b  will  be  supplied  by  NATO.  The  key  material  for  the 
TACLANE  will  be  supplied  by  the  USA  (MNIS-JPO). 

The  key  material  for  the  crypto  devices  is  provided  and  authorized  by  the  NATO  C3 
Agency  or  by  the  Multi  National  Information  Sharing  Joint  Program  Office  (MNIS  JPO)  in 
the  United  States  and  distributed  to  all  nations  according  to  authorized  memorandums  of 
agreement/procedures,  through  secure  crypto  channels.  A  valid  S-NAEC  and  l-NAEC 
are  required  in  order  to  obtain  crypto  key  material.  The  point  of  contact  for  CFBLNet  key 
material  distribution: 

NATO  C3  Agency: 


Table  4  Crypto  custodians 


NATO  CFBLNet  Comsec  PoC: 

Department/Group/Organization 

NATO  C3  Agency 

Name  including  title: 

Mr  Edgar  Harmsen 

Commercial  Phone  Number: 

+31  70  374  3488 

Internet  Email  Address: 

Edgar.Harmsen(a>.nc3a.nato.int 

Comsec  Custodian  PoC: 

Department/Group/Organization 

NC3A  Custodian 

Name  including  title: 

Mr  Cor  Westenberg-  Comsec  Custodian 

Commercial  Phone  Number: 

+31  70  374  3231 

Internet  Email  Address: 

Cor.Westenberq(a)nc3a.nato.int 
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USA: 

Table  5  Crypto  custodians 


Comsec  Custodian  (MNIS-JPO): 

Department/Group/Organization 

MNIS-JPO  (US) 

Name  including  title: 

Ron  Watkins  -  Primary  Comsec  Custodian 

Commercial  Phone  Number: 

+1  703  284  8772 

Internet  Email  Address: 

rwatkins(a>hai.com 

Comsec  Custodian  (MNIS-JPO): 

Department/Group/Organization 

MNIS-JPO  (US) 

Name  including  title: 

Charles  Plummer  -  Secondary  Comsec  Custodian 

Commercial  Phone  Number: 

+1  703  284  7004 

Internet  Email  Address: 

colummer®  hai.com 

6.4  Protocols  and  Services 

6.4.1  Protocol  translation 

The  applications  in  the  NETN  environment  use  protocols  that  are  routable  (broadcast  is 
not  routable).  This  means  that  no  protocol  translation  is  needed  when  required. 

6.4.2  Protocol  support 

The  port-numbers  of  expected  protocols  to  be  used  are  listed  below.  The  port-numbers 
can  be  used  to  filter  data  and  segregate  different  data  streams  into  separate  VLANs  and 
Ethernet  ports  in  the  initiative  switch  as  required. 

•  NTP  =123 

•  FTP  =  21 

•  DNS  =  53 

•  SNMP  =  161 

•  SMTP  =  25 

•  POP3  =  110 

•  WEB  =  80 

•  VoIP  =  ? 

•  VTC  =  ? 

Simulation  protocols  used  in  previous  projects  on  CFBLNet: 

•  DIS  =  3005  (Not  used  in  NETN) 

•  ASTI  =  5001  (Not  used  in  NETN) 

•  Link  1 1  =  1 000  Linkl 6  =  1 0000  (Not  used  in  NETN) 

•  HLA  pitch  commander  =  8070  (agent  on  each  host  running  federate),  8071 
(Commander) 

•  TNO  RTI  (HLA)  =  31 00  (RTI  exec),  3101  and  3102  (RTI  fedex),  31 03  (for 
forwarding) 

•  Mak  RTI  (HLA)  =  4000 
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Especially  for  the  simulation  protocols  the  port  numbers  to  be  used  in  a  NETN 
experiment  have  to  be  documented  in  the  Federation  Agreements  Document  (FAD) 
corresponding  to  that  specific  experiment. 


6.4.3  Quality  of  Service  (QoS) 

It  is  proposed  to  place  applications  in  different  classes  to  prioritize  network  access  and 
services  for  there  applications.  This  is  used  to  automate  the  bandwidth  assignment. 

Table  6  Access  classes  (example) 

Class  Application  Remarks 

High  VTC,  VoIP,  Low  latency 

Radio  Simulation  (HLA,  ASTi) 

Medium  Simulation  (HLA) 

Best  Effort  E-mail 


6.4.4  Network  Services 

The  network  services  available  at  this  time  on  CFBLNet  are: 

•  VoIP 

•  NTP 

•  VTC 

•  HTTP 

•  Mail 

•  FTP 

All  Network  Services  to  be  provided  by  the  NETN  network  infrastructure  are  listed  in  7.2. 

6.5  Data  flow  and  capacity 

To  make  a  total  design  the  required  services  and  their  use  (number  of  terminals 
connected  /  used  at  the  same  time  /  the  location)  are  needed.  This  gives  a  better 
perception  of  the  data  flow  between  sites  and  the  capacity  needed  to  support  the 
services,  training  and  education  systems.  This  information  should  be  documented  in 
tables  like  shown  below.  Actual  data  are  not  provided  here  for  classification  reasons. 
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Table  7  Capacity  between  countries  (Level  0) 


Country 

NATO  Country  Code 

Capacity  Mbit/s  to 
CFBLNet 

Australia 

AUS 

(data  removed) 

Bulgaria 

BGR 

(data  removed) 

Czech  Republic 

CZE 

(data  removed) 

France 

FRA 

(data  removed) 

Germany 

DEU 

(data  removed) 

Italy 

ITA 

(data  removed) 

NATO 

NATO 

(data  removed) 

Netherlands 

NLD 

(data  removed) 

Romania 

ROU 

(data  removed) 

Slovenia 

SVN 

(data  removed) 

Spain 

SPA 

(data  removed) 

Sweden 

SWE 

(data  removed) 

Turkey 

TUR 

(data  removed) 

United  Kingdom 

GBR 

(data  removed) 

United  States 

USA 

(data  removed) 

6.5.1  MTU  size  enclave  routers 

The  MTU  size  for  the  enclave  routers  will  be  1368  bytes.  (Explanation  removed  due  to 
declassification) 

6.5.2  MTU  size  enclave  crypto 

The  MTU  size  for  the  enclave  crypto  will  be  1476  bytes.  (Explanation  removed  due  to 
declassification) 

6.6  Network  topology 

6.6.1  Black  Network  (International  network) 

The  diagram  below  shows  the  top-level  design  of  the  NETN  VPN  on  top  of  the  CFBLNet 
GREEN  enclave  on  top  of  the  CFBLNet  BlackBone.  Each  nation  will  be  connected  to  the 
NETN  CFBLNet  through  its  national  access  point  or  Point-of-Presence  (PoP).  The  PoP 
will  either  connect  to  a  national  asset  located  at  that  site  or  will  provide  the  interface  to 
the  national  network  infrastructure  which  connects  national  assets. 
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Country  A 


Country  B 


Country  E 


Country  D 


Figure  13  Top  level  diagram  of  WAN 

The  diagram  below  shows  a  more  detailed  representation  of  the  CFBLNet  BlackBone 
infrastructure  that  provides  the  NETN  Enclave. 


Figure  14  CFBLNet  BlackBone  infrastructure  for  NETN  (not  completed) 


6.6.2  Crypto  network 

The  crypto  network  topology  is  the  way  the  crypto’s  are  connect  to  each  other.  There  are 
two  options  based  on  the  national  security  policy. 
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6.6.2. 1  Direct  connections 

The  first  option  is  to  make  direct  connections  between  all  sites  (international).  Each  site 
has  a  crypto  and  is  connected  to  all  other  sites.  The  national  PoP  can  have  a  crypto  as 
well,  but  the  data  can  go  directly  from  site  “1”  in  country  “A”  to  site  “1”  in  country  “B”. 


Site  A  nation  A 

Site  B  nation  A 

Site  C  nation  A 

Site  A  nation  B 

Site  B  nation  B 

Site  A  nation  C 


(All  sites  directly  connected  to  BlackBone) 


Figure  15  Crypto  Direct  Connection 

6. 6. 2. 2  Connections  through  the  national  PoP 

The  second  option  is  the  make  a  connection  through  the  national  PoP  and  then  to  the 
national  sites.  Each  site  has  a  crypto  and  is  connected  to  the  crypto  in  the  national  PoP. 
Another  crypto  in  the  national  PoP  has  connection  to  the  crypto’s  in  the  PoP  or  sites  in 
other  countries.  This  means  that  data  from  site  “1”  in  country  “A”  first  goes  to  the  national 
PoP  and  is  the  send  to  the  other  country.  Nations  may  use  a  national  crypto  system  on 
the  national  network.  Nations  can  also  include  specific  data  filters  or  other  types  of  data 
protection  or  data  translation  devices  at  the  PoP. 


Site  A  nation  A 

Site  B  nation  A 

Site  C  nation  A 

PoP  nation  A 

PoP  nation  A 

PoP  nation  B 


(Crypto  break  at  national  PoP) 

Figure  16  Crypto  Indirect  Connection  (Crypto  Break) 


6.6.3  Enclave  router  network 

Each  enclave  router  has  tunnels  to  all  other  enclave  routers  to  provide  services  needed 
in  the  enclave.  The  enclave  router  also  separates  the  different  VPN  using  the  enclave. 
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7  NETN  Network  Management  and  Network  Support  Services 

7.1  NETN  Network  Operation  Centre  (NOC) 

The  NETN  Network  Operation  Centre  (NOC)  is  a  PC  connected  somewhere  in  the 
NETN  network  managing  the  NETN  initiative  switch  and  services. 

7.2  NETN  Network  Services 

The  following  network  services  are  managed  by  NETN.  Some  of  them  are  already  part 
of  the  standard  services  provided  by  CFBLNet. 

The  Network  Services  used  in  an  experiment  have  to  be  clearly  documented  in  the 
federation  specific  FAD. 

7.2.1  Domain  Name  System  (DNS) 

Used  for  the  translation  from  host  names  to  IP  addresses. 

7.2.2  Simple  Network  Management  Protocol  (SNMP) 

Used  for  monitoring  network-attached  devices  for  conditions  that  warrant  administrative 
attention. 

7.2.3  File  Transfer  Protocol  (FTP) 

An  FTP  server  has  to  be  available  on  the  NETN  network  to  which  FTP  clients  can 
connect  for  downloading  and  uploading  files. 

7.2.4  E-Mail 

A  mail  server  (POP3  and  SMTP)  has  to  be  available  on  the  NETN  network. 

7.2.5  Voice  over  IP  (VoIP) 

Service  for  maintenance,  tech,  support  and  exercise  management. 


Figure  17  Default  enclave  IP  phone 

A  Central  Call  manager  facility  should  be  provided.  The  NOC  site  would  be  most  logical 
location. 


7.2.6  Network  Time  Protocol  (NTP) 

NTP  time  is  available  through  the  network  and  provided  by  CFBLNet.  In  time  critical 
applications  an  extra  local  time  source  is  needed  (e.g.  a  GPS  synchronised  local  clock). 
An  example  is  the  Meinberg  M300  NTP  server  using  GPS  to  synchronise. 
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Figure  18  Meinberg  M300  GPS  NTP  server 

The  need  for  such  a  local  service  depends  on  the  NETN  requirements 


7.2.7  VTC 

For  briefing  &  debriefing  in  a  distributed  environment  it  is  important  that  participants  are 
presented  with  presentation  slides  (e.g.  package  lead  briefing)  and  an  overall  tactical 
display.  Video  teleconferencing  (VTC)  is  necessary  for  interactive  discussions 
concerning  the  mission  plan  and  after  action  review  (AAR).  Obviously,  all  of  these 
interactions  fall  under  the  same  security  requirements  as  the  mission  itself.  For  this 
reason,  the  secure  network  is  also  used  for  the  VTC  and  briefing  distribution.  Besides 
communication  of  the  mission  plan  and  evaluation  of  the  executed  mission,  VTC  is  also 
important  as  part  of  Exercise  Control  and  for  managing  technical  issues. 


Figure  19  Example  VTC  Application  "Click  to  Meet" 


7.2.8  Wiki  Webserver 

A  wiki  Webserver  providing  a  Collaborative  Work  Environment  (CWE)  has  to  be  available 
on  the  NETN  network.  The  CWE  can  have  a  general  part  for  looking  up  all  kind  of  useful 
information  for  example  about  the  FOM  and  each  experiment  can  have  its  specific  part 
on  the  CWE  to  share  for  example  simulation  results.  The  current  MSG-052  and  MSG- 
068  CWEs  could  be  the  basis  of  such  a  CWE. 
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7.2.9  Quality  of  Service 

Network  management  refers  to  the  activities,  methods,  procedures  and  tools  that  pertain 
to  the  operation,  administration,  maintenance  and  provisioning  of  networked  systems. 

Operation  deals  with  keeping  the  network  (and  the  services  that  the  network  provides) 
up  and  running  smoothly.  It  includes  monitoring  the  network  to  spot  problems  as  soon  as 
possible. 

Administration  deals  with  keeping  track  of  resources  in  the  network  and  how  they  are 
assigned.  It  includes  all  the  “housekeeping”  that  is  required  to  keep  the  network  under 
control. 

Maintenance  is  concerned  with  performing  repairs  and  upgrades.  For  example,  if 
equipment  must  be  replaced  or  patches  applied  to  operating  systems  or  router/switch 
lOS’s.  Maintenance  also  includes  corrective  actions  and  preventive  measures  to  make 
the  managed  network  run  better. 

Provisioning  is  concerned  with  configuring  resources  in  the  network  to  support  a  given 
service. 

This  network  document,  while  not  all  inclusive,  is  meant  to  provide  the  basics  of  network 
operations  and  governance  of  the  networks  while  conducting  NETN  events. 

7.2.10  Network  Monitoring 

Each  nation  will  be  responsible  for  monitoring  and  maintaining  network  operations  within 
their  national  boundaries.  MNIS  JPO  is  responsible  for  monitoring  and  maintaining  the 
black  (unclassified)  network  backbone  connectivity.  The  national  CFBLNet  engineer  will 
provide  the  black  side  IP  address  schema  and  coordinate  with  the  various  national  sites 
involved  in  NETN  events  to  ensure  proper  blackside  router  configurations  to  properly 
pass  encrypted  data  traffic  and  routing  information. 

The  NETN  NOC  will  monitor  the  initiative  (classified)  network. 


MULTI  ROUTER  TRAFFIC  GRAPHER 


Figure  20  MRTG  logo 

Software  to  monitor  the  initiative  switch  is  for  instance  MRTG.  This  is  free  software.  It  is 
able  to  monitor  all  port  on  all  initiative  switches  and  presents  the  results  on  a  web  server 
for  easy  user  access  on  daily,  weekly,  monthly  and  yearly  bases. 
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Figure  21  MRTG  example  weekly  bases 
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Figure  22  WhatsUp  logo 


Other  available  monitor  software  is  “WhatsUp”.  This  is  not  free  software.  It  is  able  to 
show  the  network  configuration  and  services.  It  also  has  a  web  server  for  easy  user 
access. 


Figure  23  WhatsUp  example  for  NLD  black  network 
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8  NETN  Simulation  Interoperability  and  Simulation  Support  Services 


8.1  Simulation  Interoperability 

NETN  federations  are  based  on  NATO  STANAG  4603  which  states  that  High-Level 
Architecture  IEEE  1516  shall  be  used  as  the  standard  for  developing  and  federating 
simulation  systems. 

Non-HLA  or  legacy  HLA  (i.e.  HLA  1.3)  federates  can  participate  in  the  simulation  using 
appropriate  bridging  and/or  adapter  technologies  on  the  national  network.  Any  bridging 
required  in  order  to  adapt  federates  to  IEEE  1516  shall  be  the  responsibility  of  the 
integrating  federate. 

8.1.1  HLA-RTI  and  Central  RTI  Component  (CRC) 

NATO  STANAG  4603  implies  that  a  certified  Run  Time  Infrastructure  (RTI)  will  be  used 
to  provide  HLA  IEEE  1516  interoperability.  For  each  NETN  experiment  the  RTI  to  be 
used  has  to  be  agreed  on  and  this  choice  is  part  of  the  Federation  Agreements.  Any 
bridging  or  adaptations  of  federates  to  the  selected  RTI  shall  be  the  responsibility  of  the 
integrating  federate. 

Most  HLA  implementations  include  a  Central  RTI  Component  (CRC)  to  provide  HLA 
services  like  Time  management.  Unless  running  a  connectionless  RTI  mode  this 
component  represents  the  RTI  Executive  and  is  the  initial  point  of  access  to  a  federation. 
If  required  the  CRC  will  be  running  at  the  NOC. 

8.1.2  HLA-RTI  and  Local  RTI  Component  (LRC) 

The  Local  RTI  Component  (LRC)  is  an  integral  part  of  the  Federate  Application  and  is 
usually  started  in  the  same  process  space  as  the  federate  itself.  Usually  this  service  is 
not  documented  explicitly  in  the  FAD  unless  the  LRC  does  more  than  expected  like 
loading  a  plugin  for  SOM  to  FOM  translation. 

8.1 .3  HLA-RTI  and  Web  Service  Provider  RTI  (WSPRC) 

Web  Service  Provider  RTI  Component  (WSPRC)  is  an  RTI  component  used  when 
offering  the  RTI  services  using  the  standard  IEEE  1516  Web-Service  API. 


8.2  Simulation  Support  Services 

Simulation  Support  Services  are  processes  (software)  which  must  be  executed  in 
parallel  to  the  federate  processes  to  enable  a  federation  execution  or  which  are  required 
to  support  individual  simulations  in  the  federation  to  enable  them  to  participate  in  a 
federation  according  to  the  agreements. 

The  NETN  infrastructure  will  not  provide  any  Simulation  Support  Service  by  itself  and  it 
is  up  to  each  NETN  experiment  which  Simulation  Support  Services  are  used  and  made 
available  as  long  as  HLA  IEEE  1516  is  used  as  the  simulation  standard.  Below  some 
typical  Simulation  Support  Services  are  mentioned,  but  it  is  the  responsibility  of  the 
participants  and  not  of  the  NETN  network  to  provide  these  services. 
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The  Simulation  Support  Services  used  in  an  experiment  have  to  be  clearly  documented 
in  the  federation  specific  FAD. 

8.3  Execution  Control 

Execution  Control  software  provides  a  facility  to  remotely  startup,  monitor,  and  shutdown 
federates.  Participant  nations  can  be  required  to  install  ‘daemon  software’  on  each 
machine  that  would  be  running  a  federate.  It  is  up  to  each  NETN  experiment  whether 
execution  control  is  needed.  An  example  of  such  a  product  is  ‘Pitch  Commander’. 


8.4  Database  Services 

Specific  database  services  may  be  needed  for  providing  initialization  data 
(e.g.  scenarios,  terrain  databases,  weather  data,  weapon  system  parameters,  etc.)  or 
logging  purposes.  Access  to  the  database  services  may  given  be  through  different 
means  (e.g.  SQL,  webservices,  etc.).  An  example  is  the  Logger  tool  ’Pitch  Recorder’ 
that  uses  a  MySQL  database  for  storage. 


8.5  Bridge  or  Gateway  Services 

Bridging/gateway/adapter  services  (either  as  a  bi-directional  transfer  or  as  a  data  diode) 
may  be  required  at  federation  start-up.  Examples  are: 

0  HLA  1.3  <=>HLA  IEEE  1516 
0  FOM  X  <=>  FOM  Y 
0  DIS  <=>  HLA 
0  TENA  <=>  HLA 
0  RTI  X  <=>  RTI  Y 
0  SIMPLE  <=>  HLA  LINK  16  BOM 
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9  NETN  Infrastructure  Budget  Requirements 


9.1  CFBLNet  Business  model 

The  business  model  for  NETN  is  that  all  participants  carry  their  own  cost  to  establish  the 
connectivity.  CFBLNet  is  build  with  a  cost  sharing  philosophy  with  pay  as  you  go:  every 
participant  (NATO  nation,  NATO  organisation  and  Guest  Nations  fulfil  their  own  cost  to 
connect  and  together  they  share  the  common  cost  (total  shared  cost/numbers  users). 
The  National/Organisation  cost  is  internally  handled. 

National  Cost: 

•  Non-recurring: 

o  National  Infrastructure 
o  Initial  installation 

•  Recurring: 

o  Link  cost  to  nearest  PoP. 
o  Monthly  subscription  cost  (shared  element). 


9.2  CFBLNet  Subscription  Costs 


9.2.1  CFBLNetwork  Cost  Estimates 

The  cost  estimate  is  made  under  the  condition  that  a  10  Mbit/s  capacity  is  needed  for 
NETN. 

The  subscription  costs  for  CFBLNet  (2009)  are: 

o  One  time  Installation  cost:  EURO  4k  (E3  connection) 
o  Monthly  fee 

o  4  Mbit/s  (default):  EURO  7k 
o  10  Mbit/s  (during  training)  EURO  9k 

These  Subscription  costs  are  covering  the  shared  Infrastructure  hardware/software, 
CFBLNet  Management  and  Coordination,  helpdesk,  standard  services  including  Network 
Management,  encryption,  routing,  DNS,  mail,  voice  (over  IP  (VoIP)),  Web  and  FTP 
services,  Network  time  protocol  (NTP)  and  full  transparent  access  to  the  CFBLNet  core 
network  including  transatlantic  connections.  On  request  VTC  can  be  added  as  a  service. 
The  Installation  cost  include  extensive  coordination  and  installation  efforts  to  get  the 
links  and  blackbone  routers  interconnected  and  configured  between  the  national  PoP 
and  the  CFBLNet  PoP  facilities. 
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Figure  24  NATO  and  European  CFBLNet  Point  of  Presence. 


A  permanent  subscription  provides  standard  access  to  the: 

•  CFBLNet  Blackbone  (IPv4  (IPv6)  transport  network) 

•  CFBLNet  CUE  (Unclassified  Enclave  all  participants) 

•  CFBLNet  BLUE  *  (Coalition  Secret  Rel.  ASCANZUKUS+NATO  (nations  and 
organisation) 

•  CFBLNet  RED  *  (NATO  Secret  Rel.  NATO  (nations  and  organisation) 

•  Access  when  applicable 

However,  a  permanent  subscription  on  CFBLNet  is  already  in  place  for  most  of  the 
NETN  countries.  This  means  that  these  CFBLNet  costs  can  be  shared  with  other 
initiatives  in  that  country  (e.g.  CWID).  Maybe  additional  CFBLNet  cost  for  extra 
bandwidth  is  needed  during  execution.  As  an  example  for  these  nations  with  a 
permanent  CFBLNet  subscription  the  NETN  cost  would  only  be  EURO  9k  /  Month  per 
1 0Mbit/s  during  training.  This  depends  from  country  to  country.  Contact  you  national 
CFBL  representative  for  more  information. 
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Table  8  CFBLNet  subscription 


Country 

NATO  Country  Code 

Permanent  CFBLNet 
subscription  in  place 

Australia 

AUS 

YES 

Bulgaria 

BGR 

NO 

Czech  Republic 

CZE 

NO 

France 

FRA 

YES 

Germany 

DEU 

YES 

Italy 

ITA 

YES? 

NATO 

NATO 

YES 

Netherlands 

NLD 

YES 

Romania 

ROU 

NO 

Slovenia 

SVN 

NO 

Spain 

SPA 

Not  permanent 

Sweden 

SWE 

Not  permanent 

Turkey 

TUR 

NO 

United  Kingdom 

GBR 

YES 

United  States 

USA 

YES 

9.2.2  International  network  Costs 

The  cost  for  the  international  connection  between  the  nation  and  the  CFBLNet  hub  at 
NC3A  (The  Hague,  The  Netherlands)  is  often  already  paid  for  by  the  national  part  of  the 
CFBLNet  organisation.  This  means  that  these  CFBLNet  costs  can  be  shared  with  other 
initiatives  in  that  country.  The  connection  costs  for  each  country  are  for  that  country. 

As  an  example,  the  network  cost  for  a  connection  between  NC3A  and  Istanbul  for  an  E3 
(34  Mbit/s)  leased  line  will  amount  to  about  EURO  4k  /  month  with  a  contract  for  at  least 
one  year.  Note  that  the  available  capacities  of  lease  lines  is  2,  8,  10  (different 
technology)  or  34  Mbit/s.  In  general,  the  34Mbit/s  line  has  the  best  price-performance. 
On  request,  CFBLNet  could  provide  the  link  between  your  National  PoP/Site  and  the 
NATO  and  European  CFBLNet  PoP.  However,  experience  learned  that  national  service 
providers,  through  National  MOD’S,  provide  better  arrangements. 


9.2.3  National  network  Costs 

The  cost  for  the  national  connection  is  often  already  paid  by  the  national  part  of  the 
CFBLNet  organisation.  This  means  that  these  CFBLNet  costs  can  be  shared  with  other 
initiatives  in  that  country.  The  site  connection  costs  are  for  the  country.  No  additional  fee 
is  required  for  that  national  connection  to  NC3A. 

9.2.4  CFBLNet  National  PoP  /  Access  node  considerations 

Depending  on  the  national  organisational  arrangements  a  nation  can  decide  to  initially 
connect  only  one  national  site  to  CFBLNet.  If  more  national  sites  would  like  to  participate 
it  is  recommended  to  establish  a  National  PoP. 

9.2.4. 1  National  CFBLNet  PoP  setup  cost 

Cost  of  equipment  for  PoP  differs  from  country  to  country  and  the  national  security  rules. 
To  setup  a  CFBL  PoP  starts  with  about  30K  EURO  for  hardware  and  software 
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9. 2.4. 2  Natonal  CFBLNet  Site  setup  cost 

Cost  of  equipment  for  a  new  site  is  around  30K  EURO  for  hardware  and  software 


Initiative  A  Initiative  B 


Initiative  Switch 


Enclave  router 


Approved  crypto 


Black  site  router 


Figure  25  Site  network  equipment 
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2  Introduction 

This  document  is  a  deliverable  of  the  MSG-068  NETN  Infrastructure  Working  group  and  provides  a  detailed  infrastructure  test 
protocol  description  and  recommendations  for  its  implementation.  The  document  refers  to  the  NETN  Infrastructure  Design  that  was 
proposed  and  discussed  in  [Annex  D  MSG-068  NETN  Network  Infrastructure  Design  Document], 

Note  that  within  the  given  constraints  of  time  and  resources,  the  NETN  Infrastructure  team  has  performed  a  subset  of  these  tests 
during  the  preparation  and  the  execution  of  the  MSG-068  NETN  experiments  in  Nov  2010.  The  test  results  as  collected  for  the  NETN 
infrastructure  used  in  the  experiment  are  included  in  the  final  paragraph  of  this  document. 
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3  Test  protocol  Overview 

There  are  two  kinds  of  network  tests  foreseen.  The  first  is  before  the  initiative  starts  (pre  initiative  test)  and  the  other  is  during  the  initiative 
(monitoring  test). 

The  pre  initiative  test  is  to  determine  the  default  parameter  values  as  available  bandwidth  protocols  and  services.  The  monitoring  test  is  to  detect 
problems.  This  monitoring  information  can  then  be  used  to  solve  (network  or  application)  problems  immediately  if  possible  or  the  use  this 
information  to  improve  new  initiatives. 

It  is  difficult  to  describe  a  standard  (‘one  size  fits  all’)  test  protocol  because  initiatives  are  so  different.  In  this  document  examples  are  presented  to 
take  care  of  most  common  issues  in  an  initiative. 

3.1  Pre  initiative  test 

In  the  pre  initiative  test  the  following  parameters  are  essential  to  predict  the  influence  of  the  network  on  most  applications.  The  requirements  and 
implementation  determine  if  all  tests  should  be  done. 

•  Maximum  Bandwidth 

o  For  different  protocols  (TCP,  UDP) 
o  For  different  data  classes 

•  Delay  between  all  sites  for  different  packet  sizes 

•  Routing  (unicast,  multicast) 

•  Protocols  (TCP,  UDP,  multicast,  broadcast) 

•  Reachable  services  (NTP,  DNS,  x,  x,  x) 

•  Max  MTU  size  /  fragmentation 

These  tests  should  be  carried  out  on  the  classified  side  of  the  network.  If  this  is  not  possible  due  to  accreditation  issues  an  indication  on  the 
unclassified  side  can  be  used  for  the  following  parameters: 

•  Bandwidth 

•  Delay  to  all  sites 

3.2  Monitoring  test 

In  the  monitoring  test  the  following  information  of  the  classified  network  is  important  to  find  problems: 

•  Used  Bandwidth  for  the  protocols  used 
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Delay  between  all  sites 
Reachable  services 
Fragmentation 
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4  Test  protocol 

4. 1  Security 

Be  aware  that  no  unclassified  computer  is  connected  to  the  classified  network! 

Be  aware  that  no  classified  computer  is  connected  to  the  unclassified  network! 

Do  not  use  DHCP  on  computers.  Different  IP  address  ranges  are  the  first  line  of  defense  for  computers  connected  to  the  incorrect  network! 

4.2  Hardware  needed 

■  Unclassified  PC  (any  computer) 

■  Classified  PC  (any  computer) 

■  Classified  SERVER  LINUX 

■  Classified  SERVER  WINDOWS  SERVER  2008 

For  information  about  the  server  hardware  see  Appendix  E.1 . 

4.3  Network  and  test  device  initialization 

4.3.1  Routers  and  switches 

Do  NOT  set  router  and  switch  Ethernet  ports  to  auto.  This  often  shows  bad  behavior  when  the  network  becomes  “loaded”. 

4.3.2  Computers  and  SERVERS 

Do  NOT  set  Computers  and  SERVERS  Ethernet  ports  to  auto.  This  often  shows  bad  behavior  when  the  network  becomes  “loaded”. 

4.4  Network  pre  initiative  test 

4.4.1  Check  router  tables  black  routers 

The  command  “ship  route”  should  show  all  active  routs  to  all  connected  routers. 

4.4.2  Check  router  tables  red  routers 

The  command  “ship  route”  should  show  all  active  routs  to  all  connected  routers. 
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4.4.3  Black  site  Connectivity  and  delay 

The  ‘Ping’  is  a  simple  test  and  gives  information  about  the  connectivity  and  delay  between  two  systems.  The  protocol  used  is  ICMP  and  is  based 
on  UDP.  The  Ping  command  is  available  on  each  Windows  and  Linux  PC.  This  test  also  shows  if  there  is  a  problem  with  a  crypto  or  Ethernet 
network  port  along  the  way. 

PING  all  connected  routers  in  the  unclassified  network  to  test  if  all  sites  can  be  reached. 

The  PING  also  provides  “min”,  “average”  and  “maximum”  round  trip  delay  times.  The  PING  length  should  be  set  to  the  following  length: 


PING 

Remarks 

Size 

RTT 

1 00  bytes 

500  bytes 

1 000  bytes 

2000  bytes 

3000  bytes 

5000  bytes 

If  this  test  shows  a  loss  of  data  then  there  is  probably  a  network  port  set  to  “auto”  in  the  path.  If  there  is  packet  loss  the  problem  should  be  solved 
before  the  other  tests  could  be  done. 

4.4.4  Red  site  Connectivity  and  delay 

PING  all  connected  routers  in  the  classified  network  to  test  if  all  sites  can  be  reached.  The  PING  also  provides  “min”,  “average”  and  “maximum” 
round  trip  delay  times.  The  PING  length  should  be  set  to  the  following  length: 


PING 

Remarks 

Size 

RTT 

1 00  bytes 

500  bytes 

1 000  bytes 

2000  bytes 

3000  bytes 

5000  bytes 

If  this  test  shows  a  loss  of  data  then  there  is  probably  a  network  port  set  to  “auto”  in  the  path.  If  there  is  packet  loss  the  problem  should  be  solved 
before  the  other  tests  could  be  done.  Experience  has  shown  that  also  a  crypto  could  initiate  packet  loss  at  longer  packets  (Restart  all  crypto’s 
involved). 
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4.4.5  Unclassified  PC  configuration 

To  optimize  the  network  capacity,  the  maximum  transmission  unit  (MTU)  size  is  determined.  This  will  be  done  with  the  program  TCP  optimizer. 


Figure  1  TCP  optimizer 

After  the  MTU  size  determination  the  connection  speed  is  set  to  20.000  and  Optimized  settings  is  set  and  fixed  with  Apply  changes.  This  initialized 
the  computer  for  best  network  performance. 

4.4.6  Classified  PC  configuration 

To  optimize  the  network  capacity,  the  maximum  transmission  unit  (MTU)  size  is  determined.  This  will  be  done  with  the  program  TCP  optimizer. 
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Figure  2  TCP  optimizer 

After  the  MTU  size  determination  the  connection  speed  is  set  to  20.000  and  Optimized  settings  is  set  and  fixed  with  Apply  changes.  This  initialized 
the  computer  for  best  network  performance. 

4.4.7  Black  site  bandwidth  test 

The  TCP  and  UDP  network  capacity  is  tested  with  JPerf.  This  will  provide  information  in  the  peak  and  average  capacity  of  the  network. 
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Figure  3  JPerf 


4.4.7. 1  JPERF  Client  unclassified  Configuration 

Server  address  t.b.d. 

Port  5001 

Parallel  streams  1 

Application  layer  options 

Transmit  10  seconds 

Output  Kbit/s 

Report  interval  1  second 
Test  port  5001 
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Transport  layer  options 

TCP 

Buffer  length  t.b.d. 

TCP  window  size  t.b.d. 

Max  segment  size  t.b.d. 

TCP  no  delay  (off) 

UDP 

UDP  bandwidth  t.b.d. 

UDP  buffer  size  t.b.d. 

UDP  packet  size  t.b.d. 

IP  layer  options 

TTL  1 

T ype  of  service  None 

Bind  to  host  t.b.d. 

IPv6  (off) 


4.4. 7.2  JPERF  Server  unclassified  Configuration 


Listen  Port  5001 

Client  limit  t.b.d. 

N  u  m  ber  of  con  nections  1 

Application  layer  options 

Transmit  10  seconds 

Output  Kbit/s 

Report  interval  1  second 

Test  port  5001 

Transport  layer  options 

TCP 

Buffer  length  t.b.d. 

TCP  window  size  t.b.d. 

Max  segment  size  t.b.d. 

TCP  no  delay  (off) 

UDP 

UDP  bandwidth  t.b.d. 
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UDP  buffer  size  t.b.d. 

UDP  packet  size  t.b.d. 

IP  layer  options 

TTL  1 

Type  of  service  None 

Bind  to  host  t.b.d. 

IPv6  (off) 


4.4.8  Red  site  bandwidth  test 

The  TCP  and  UDP  network  capacity  is  tested  with  JPerf.  This  will  provide  information  in  the  peak  and  average  capacity  of  the  network. 


Figure  4  JPerf 
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4.4.8. 1  JPERF  Client  classified  Configuration 

Server  address  t.b.d. 

Port  5001 

Parallel  streams  1 

Application  layer  options 

Transmit  10  seconds 

Output  Kbit/s 

Report  interval  1  second 
Test  port  5001 

Transport  layer  options 

TCP 

Buffer  length  t.b.d. 

TCP  window  size  t.b.d. 

Max  segment  size  t.b.d. 

TCP  no  delay  (off) 

UDP 

UDP  bandwidth  t.b.d. 

UDP  buffer  size  t.b.d. 

UDP  packet  size  t.b.d. 

IP  layer  options 

TTL  1 

Type  of  service  None 

Bind  to  host  t.b.d. 

IPv6  (off) 

4.4. 8.2  JPERF  Server  classified  Configuration 

Listen  Port  5001 

Client  limit  t.b.d. 

Number  of  connections  1 
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Application  layer  options 

Transmit 

Output 

Report  interval 
Test  port 


1 0  seconds 
Kbit/s 
1  second 
5001 


Transport  layer  options 

TCP 

Buffer  length  t.b.d. 

TCP  window  size  t.b.d. 

Max  segment  size  t.b.d. 

TCP  no  delay  (off) 

UDP 

UDP  bandwidth  t.b.d. 

UDP  buffer  size  t.b.d. 

UDP  packet  size  t.b.d. 


IP  layer  options 

TTL  1 

Type  of  service  None 

Bind  to  host  t.b.d. 

IPv6  (off) 


4.5  Network  monitoring  during  pre  initiative  test  and  initiative 

The  network  monitoring  system  consists  of  two  centralized  19”  servers.  One  server  uses  LINUX  as  operating  system  and  the  other  server  is  using 
WINDOWS  SERVER  2008  as  operating  system.  These  two  servers  monitor  the  network  and  provide  all  sites  connect  with  the  network  status 
information  on  a  web  based  interface. 

4.5.1  Network  devices 

Network  devices  such  as  routers  and  switches  need  to  provide  access  to  the  network  tools.  This  means  that  Simple  Network  Management 
Protocol  (SNMP)  “READ”  access  is  needed  by  the  network  management  and  monitoring  tools. 

4.5.1 .1  Router  and  switch  configuration 

To  provide  read  access  for  the  network  management  and  monitoring  tools  the  following  information  should  be  added  to  CISCO  network  device 
configuration  (example  for  TNO  in  The  Hague): 
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snmp-server  community  !NETN@CFBL#$!  RO 
snmp-server  location  NLD,  TNO,  The  Hague 
snmp-server  contact  phone:  +31651096151 
! 

4.5.2  Server  1  LINUX 

For  information  about  the  server  hardware  see  Appendix  E.1 . 

4.5.2. 1  MRTG 

MRTG  is  using  the  Simple  Network  Management  Protocol  (SNMP)  to  get  information  from  network  devices. 

X 

X  Diagram  not  available 
X 

4. 5. 2. 1.1  MRTG  Configuration 

The  MRTG  configuration  depends  on  the  detailed  implementation.  Therefore  it  is  not  possible  to  describe  that  at  this  stage. 

4.5.3  Server  2  Windows 

For  information  about  the  server  hardware  see  Appendix  E.1 . 

4.5.3. 1  WhatsUp  Gold 

WhatsUp  Gold  is  network  management  software.  PING  and  Simple  Network  Management  Protocol  (SNMP)  protocols  are  used  to  test  connectivity 
to  devices  and  to  request  status  information  from  these  devices.  The  software  provides  delay  information  to  all  devices  and  if  the  devices  are 
reachable  by  SNMP  and  is  allowed  to  have  access  also  bandwidth  and  error  information  for  each  port  used  on  that  device  is  available. 


WhatsConnected 


The  tool  also  has  a  build  in  web-server.  This  makes  it  easy  to  access  it  with  a  standard  web  browser  from  different  locations  while  it  is  on  one  site 
installed. 
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4. 5. 3. 1.1  Whats  Up  gold  Configuration 

The  WhatsUp  configuration  depends  on  the  detailed  implementation.  Therefore  it  is  not  possible  to  describe  that  at  this  stage. 


4. 5. 3.2  MTRG 

Multi  Router  Traffic  Grapher  (MTRG)  is  free  software  and  available  for  windows  and  Linux.  For  live  Traffic  graphs  of  GEANT  2 
network  see:  http://www.switch.ch/network/operation/statistics/qeant2.html 

MRTG  shows  live  and  history  information  about  network  devices  (Used  bandwidth,  delay,  errors).  It  is  able  to  monitor  all  ports  on  all 
initiative  switches  and  presents  the  results  on  a  web  server  for  easy  user  access  on  daily,  weekly,  monthly  and  yearly  bases. 
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Figure  6  Network  load  NLD  during  CDEP  initiative  (NLD  <>CFBL  connection) 


4. 5. 3.2.1  MTRG  Configuration 

The  MTRG  configuration  depends  on  the  detailed  implementation.  Therefore  it  is  not  possible  to  describe  that  at  this  stage. 


4. 5. 3. 3  Wireshark 

Wireshark  is  a  monitoring  tool.  The  tool  can  look  deep  in  the  IP  packet  and  show  the  interpretation  of  bits  in  the  received  packet  header.  This 
makes  it  possible  to  detect  fragmentation,  find  problems  in  for  instance  multicast  associations  and  so  on.  The  problem  is  that  it  has  to  be  installed 
on  the  site  and  remote  management  is  not  possible  other  then  a  remote  desktop  connection.  Wireshark  is  a  free  tool. 
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Figure  7  Wireshark  window 


4. 5. 3. 3.1  Wireshark  Configuration 

The  Wireshark  configuration  depends  on  the  detailed  implementation.  Therefore  it  is  not  possible  to  describe  that  at  this  stage. 
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5  Test  Results  and  Conclusions  from  the  NETN  Experiment 

5.1  Intro 

The  MSG-068  Infrastructure  Subgroup  developed  the  initial  network  topology  design  for  the  Experiments.  The  Infrastructure  consisted  of  three 
variants: 

•  Unclassified  Network  Infrastructure  using  Internet 

•  Unclassified  Network  Infrastructure  using  CFBLNet  over  Internet  backbone 

•  Unclassified  Network  Infrastructure  using  CFBLNet  over  NATO  NGCS  backbone 
The  latter  two  options  are  closely  related  and  will  be  discussed  together. 


5.1.1  Unclassified  Network  Infrastructure  over  Internet 

The  Internet  was  used  during  most  of  the  preparation  and  testing  for  the  Experiment.  In  order  to  simplify  the  network  configuration  of  the  assets 
(IP  ranges,  Firewall  settings  etc)  a  tool  supplied  by  Sweden  was  used.  This  tool  is  named  ‘Booster’.  It  provides  a  type  of  Virtual  Private  Network  for 
HLA  related  traffic.  The  sites  install  a  local  client  and  a  central  server  node  is  available  to  monitor  the  network  and  node  activity,  participating 
federates  and  other  information.  The  Booster  server  was  located  in  Linkoping  Sweden  during  the  preparation  phase  and  in  Bydgoszcz  (Poland) 
during  the  experiment. 
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CRC1 1 :  NETN_R ADIO:  VBS2  UK  Raclio[7] 


CRC11:  Unjoined 


CRC11 

CRC1 1  :NETN2:  Pitch  Actors[28] 
CRC1 1  :NETN_RADIO:TYR  Radio[27] 

CRC1 1 :  NETN:  PitchRecorder[1 7] 

CRC1 1 :  NETN_R ADIO:  VBS2  TNO  Radio[8] 

CRC1 1 :  NETN2:  CATST  YR[33] 

CRC1 1  :NETN_RADIO:RTI_Radio[S] 

CRC1 1  :NETN2:  Pitch  Actors[9] 
CRC1 1  :NETN2:  CATST  YR[36] 


CRC1 1  :NETN_R  ADIO:  Audience  AudioRadio[1 4] 

CRC1 1  :NETN_R ADIO:  ICC  Op  Radio[1 9] 

<f\  CRC1 1 :  NETN_RADIO:  FedExRadio[1 2] 

JFTC 

Q  CRC11:  Unjoined 
O  CRC11:  Unjoined 

^  CRC11:NETN_R ADIO:  Stealth  Op  Radio[18] 


CRC11:  Unjoined 

CRC11:  Unjoined 


CRC11:NETN_R  ADIO:  Paris 


Radio[1 1  ] 


Figure  8  Booster  Network  Overview  Diagram 


5.1.2  Unclassified  Network  Infrastructure  over  CFBLNet 

The  MSG-068  Infrastructure  Subgroup  developed  the  initial  network  topology  design  for  the  Experiments.  The  Infrastructure  was  based  on 
CFBLNet.  Given  the  nature  of  the  experiments  (unclassified,  technical  feasibility  demonstration)  and  the  available  resources,  the  decision  was 
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taken  to  establish  the  NETN  Infrastructure  on  an  existing  CFBLnet  Unclass  Enclave  (CUE),  also  known  as  White  Enclave  ((future)  Standing  Class 
Enclave).  The  necessary  paperwork  (CFBLNet  Initiative  Information  Package  CIIP)  was  produced  in  collaboration  with  the  nations  and  the 
CFBLnet  organization.  The  proposed  topology  with  planned  bandwidths  is  shown  in  the  diagram  below.  Note  that  a  permanent  Infrastructure 
solution  should  establish  a  dedicated  NETN  Enclave  under  CFBLNet  to  simplify  and  streamline  the  process  of  setting  up  an  exercise  or 
experiment. 


;  i 


Research  &  Technology  Organisation 


NETN-U  Initiative  on 

CFBL  Net  Unclassified  Standing  Enclave 


CATOD,  Paris 
FRA-xxx 


JFTC,  Bydgoszcz 
(Site  +  POP): 
NATO  012 


4  Mbit 


10  Mbit 


FRA  POP,  Celar.Brui 
FRA-001 


NC3A,  The  Hague 


10(45)  Mbit 


Figure  9  CFBLNet  Topology  as  planned  for  MSG-068  NETN  Experiment 
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Due  to  resource  and  scheduling  issues  the  final  topology  that  was  used  in  the  NETN  Experiment  differed  from  the  proposal  in  two  ways: 

•  Site  Ottobrunn  in  Germany  could  not  be  connected  and  thus  The  German  team  did  not  participate  in  the  CFBLnet  based  Experiments. 

•  Site  Stockholm  in  Sweden  could  not  be  connected  and  the  Swedish  team  moved  to  The  Hague,  Netherlands  to  participate  in  the  CFBLnet 
based  Experiments. 

•  The  UK  used  the  site  Porton  Down  and  did  not  bring  Industry  sites  on-line. 

The  Spanish  team  moved  to  CATOD,  Paris  during  the  Experiment  as  was  planned  during  the  design  phase.  Note  that,  according  to  plan,  several 
other  Team  members  used  the  site  in  Bydgoszcz  to  connect  their  assets. 

The  CFBLNet  was  implemented  under  supervision  of  the  CFBLnet  national  Technical  POCs.  Unfortunately  several  sites  came  on-line  only  shortly 
before  the  Experiment  started.  This  was  due  to  resource  issues  as  well  as  to  accreditation  issues  that  needed  more  time  to  sort  out  than  what  was 
expected.  This  resulted  in  very  limited  opportunity  for  testing  federates  running  over  CFBLnet  before  the  actual  Experiment  started. 

The  NETN  Infrastructure  was  largely  based  on  an  existing  CFBLnet  Unclass  Enclave  (CUE).  The  new  ‘legs’  (e.g.  The  Hague-Bydgoszcz)  were 
initially  planned  to  run  on  an  NGCS  backbone.  Due  to  performance  concerns  an  alternative  was  also  tested  that  used  (encrypted)  Internet 
backbones.  This  Internet-based  setup  provided  good  performance,  although  no  Quality  of  Service  could  be  guaranteed. 


5.2  Pre  initiative  test 

In  the  pre  initiative  test  information  was  collected  based  on  available  measured  CFBLNet  network  parameters  and  based  on  specific  Ping  tests 
that  provided  connectivity  and  delay  information.  The  tests  were  done  on  the  unclassified  side  of  the  network  (Appendix  E.4).  Testing  opportunities 
were  very  limited  due  to  late  availability  of  the  Infrastructure. 


Setup  wise  there  were  two  types  of  networks  being  used,  namely  ordinary  Internet  or  CFBLNet.  The  CFBLNet  type  was  also  evaluated  in  two 
different  flavors,  standard  CFBLNet  over  NGCS  as  well  as  CFBLNet  over  encrypted  Internet.  The  ordinary  Internet  connection  contained  no 
encryption  or  other  security  measures  beyond  the  booster  encapsulation  of  data.  Also,  no  traffic  prioritization  improvements  were  possible  on  the 
Internet  connection.  The  CFBLNet  over  NGCS  has  QoS  and  Routing  control  since  all  traffic  is  routed  through  a  separate  internal  network  that  is 
laid  in  parallel  with  the  regular  Internet  connection.  Due  to  ping/latency  problems  when  using  CFBLNet  over  NGCS  between  Bydgoszcz  and  The 
Hague  a  separate  CFBLNet  connection  over  encrypted  Internet  was  tested.  This  encrypted  Internet  connection  of  course  had  the  same 
shortcomings  as  the  normal  Internet  connection  since  the  same  basic  layer  of  connectivity  was  used. 


5.3  Monitoring  test 

In  the  monitoring  test  the  following  information  of  the  classified  network  is  important  to  find  problems: 
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•  Used  Bandwidth  for  the  protocols  used 

•  Delay  between  all  sites 

•  Reachable  services 

•  Fragmentation 

In  the  Hourly  Throughput  below  (Figure  1 1 )  a  trend  can  be  seen  in  that  Bandwidth  usage  increased  steadily  over  the  course  of  the  experiment. 
This  is  mainly  due  to  an  increased  number  of  participants  and  increased  radio  traffic  between  actors.  The  experiment  was  conducted  with  NGCS 
over  encrypted  Internet.  This  caused  perceived  problems  in  that  the  training  audience  experienced  failures  in  radio  communication,  mostly  in  the 
form  of  breakups  in  transmissions.  A  note  about  this  is  that  there  is  no  prioritization  being  performed  during  any  of  the  stages  now,  neither  on  the 
network  layers  nor  in  the  booster  overlay.  Following  to  this  experiment  a  new  network  traffic  ordering  and  prioritizing  transport  scheme  is  tested  in 
the  booster.  The  main  difference  is  that  not  any  one  federate  is  allowed  to  send  for  more  than  a  short  period  of  time,  i.e.  a  round-robin  pattern. 
Latency  wise  the  connection  was  very  good  though,  the  problems  perceived  were  of  the  bandwidth  and  prioritization  nature. 


Current  Day  Throughput 


Figure  10  Daily  Throughput  (Afternoon  3  nov  2010  -  Morning  4  nov  2010) 
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□  throughput 


14:00  14:10  14:20  14:30  14:40 

Min:  422.0k  Max:  3.3M  Aug:  1 . 7M  Current:  321.4k 


Figure  11  Hourly  throughput  during  NLVC  Experiment  (Afternoon  4  nov  2010) 


The  Booster  monitor  visualizes  the  increased  number  of  participants  and  connections  during  the  experiment. 
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CRC11 

CRC1 1 :  NETN:  TNO  Gateway[23]  '  _ 
CRC1 1 :  NETN_R  ADIO:  RTI_Radio[2] 

CRC11:  NETN:  LVCGameType[9] 

CRC1 1 :  NETN_R ADIO:  VBS2  TNO  Radio[5] 


Budapest 


Madrid 


TNO 


CRC1 1 :  NETN_R ADIO:  VBS2  UK  Radio[1 3] 


O 


Paris 


o 


CRC1 1  :NETN:  VRFGUI[25] 
CRC1 1 :  NETN:  VR-Forces[24] 


Linkoping 


ennart@Pitch 


o 


JFTC 


Plexsys 


o csxxe£> 

CRC1 1  :NETN:GEadapter[1 6]  - 

CRC11:NETN_R ADIO:  ICC  Radio[6]  I  I 
CRC1 1  :NETN:  JCATS[26]  I 
CRC11:  NETN_R  ADIO:  FedExRadio[7] 


CRC11:NETN:MAK  Stealth[12] 

I  I  CRC11:NETN_RADIO:  Stealth  Op  Radio[1 5] 
CRC11:  NETN_R  ADIO:  Audience  AudioRadio[1 1  ] 
CRC1 1  :NETN:FLAMES[29] 

:RC11:NETN:MAK  PVD[8] 


El  RTI  Exec  O  Federate  A.  Commander  ^  Agent  (0  Booster  (•)  Home  Booster  (^)  Offline  Booster 

Figure  12  Booster  Network  Overview  Diagram  (Internet  Experimentation) 


On  average  the  network  bandwidth  did  not  exceed  3  Mbit/s.  However,  this  depends  highly  on  the  events  (interactions)  taking  place 
during  the  exercise  and  in  particular  on  the  radio  traffic  which  consumes  much  bandwidth.  A  problem  remains  that  we  (engineers)  still 
don’t  have  good  way  to  specify  what  capabilities  the  network  needs  to  have  for  a  specific  set  of  federates  and  a  specific  scenario.  This  includes 
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estimating  the  data  rates  that  result  from  typical  manoeuvring  that  operational  pilots  execute  during  missions  and  the  impact  of  radio/voice 
transmissions  on  the  required  bandwidth. 

The  MSG-068  experience  with  CFBLNet  showed  that  this  infrastructure  shows  promise  but  has  not  yet  achieved  a  good  grip  on  providing  a 
guaranteed  service  level  wrt  bandwidth,  latency  etc. 
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6  Referenced  publications 

1.  CFBLNet-Publ-  Main-V6.0-U 

2.  CFBLNet-Publ  -  Annex  A-V6.0-U 

3.  CFBLNet-Publ  -  Annex  B-V6.0-U 

4.  CFBLNet-Publ  -  Annex  C-V6.0  Appendices-U 

5.  CFBLNet-Publ  -  Annex  C-V6.0-U 

6.  CFBLNet-Publ  -  Annex  D-V6.0  Appendices-UNRI 

7.  CFBLNet-Publ  -  Annex  D-V6.0-U 

8.  CFBLNet-Publ  -  Annex  E-V6.0 

9.  CFBLNet-Publ  -  Annex  F-V6.0 

10.  CFBLNet-Publ  -  Annex  G-V6.0-U 

1 1 .  NATO  STAN  AG  4603  -  HLA 

12.  IEEE  1516  HLA 

13.  lEEEStd  1278.1a-1998 

IEEE  Standard  for  Distributed  Interactive  Simulation  -  Application  Protocols 
18  august  1998,  New  York 

14.  lEEEStd  1278.1-1995 

IEEE  Standard  for  Distributed  Interactive  Simulation  -  Application  Protocols 

15.  IST-CF-98-07 

Enumeration  and  Bit  Encoded  Values  for  Use  with  Protocols  for  Distributed  Interactive  Simulation  Applications.  This 
document  accompanies  IEEE  Std.  1278.1-1995  and  IEEE  Std.  1278. la-1998  June  20,  1998 

16.  MSG-068  NETN  Network  Infrastructure  Design  Document  (Annex  D  of  this  report) 
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Appendix  E.1  NETN  SERVER  Hardware 
DELL™  PowerEdge™  R200  (SV4R200)  €  730,00 


Module 

description 

Base 

Dual  Core  Intel®  Xeon®  E3120,  3.16GHz,  6MB  Cache,  1333MHz  FSB 

Memory 

4  GB  Memory,  DDR2,  800  MHz  (2  x  2GB  Dual  Ranked  DIMMs) 

Optical  drive  stations 

16  X  DVD  +/-  RW  Drive  SATA 

1  st  hard  drive 

250  GB,  SATA,  3.5-inch,  7.2K  RPM  Hard  Drive  (Cabled) 

2  de  hard  drive 

250  GB,  SATA,  3.5-inch,  7.2K  RPM  Hard  Drive  (Cabled) 

1  st  RAID-  or  SCSI-controller  card 

SAS  6iR  internal  RAID  Controller,  PCI-Express 

RAID-connectivity 

C4  -  Add-in  SAS  6iR  (SATA  /  SAS  Controller)  which  supports  2  Hard  Drives  -  RAID  1 

Rails  rack  montage 

Rack  Rails  Static  Rapid 

Extension  card 

Riser  with  PCI-E  Support  (1  x  PCI-E  x8  slot,  lx  PCI-E  x4  slot) 

System  management 

Open  Manage  Software  loaded  and  DVD  Kit 

Operating  System 

Not  Included 

Bezel 

Power  Edge  R200  Bezel  Assembly 
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Appendix  E.2  NETN  Client  Hardware 

Module 

Base 

Memory 

Optical  drive  stations 

1  st  hard  drive 

2  de  hard  drive 

1  st  RAID-  or  SCSI-controller  card 

RAID-connectivity 

Rails  rack  montage 

Extension  card 

System  management 

Operating  System 

Bezel 
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Appendix  E.3  NETN  Infrastructure  Test  Tool  Specifications 


Tool  Description 

Operating 

system 

Version 

Date 

Vendor 

Website 

Approx. 

Costs 

Remarks 

WhatsUp  Gold 

windows 

E  2000,- 

MRTG 

LINUX 

latest 

MRTG 

free 

Multi  Router  Traffic 
Grapher  (MTRG)  is  free 
software  and  available 
for  windows  and  Linux. 
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Appendix  E.4  Measured  Average  Delay  between  National  CFBLNet  PoPs  (January  2009) 

CFBLNet  BlackBone 
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GRB 
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24 

25 

30 

HO 

1 
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NLD 
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170 

24 

25 

30 
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NZL 
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SWE 

All  times  are  in  milliseconds 
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NETN  enclave  (Data  removed  due  to  declassification) 


AUS 

CAN 

DEU 

FRA 

GRB 

ITA 

NATO 

NLD 

NZL 

USA 

SWE 

AUS  I 

CAN 

DEU 

FRA 

GRB 

ITA 

NATO 

NLD 

NZL 

USA 

SWE 

All  times  are  in  milliseconds 
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Background 

This  Federation  Agreements  Document  (FAD)  support  the  development  and  execution  of  a  federated  distributed  simulation  based  on  NATO 
Education  and  Training  Network  (NETN)  Federation  Architecture  and  FOM  Design  (FAFD)  recommendations  made  by  the  NATO  RTO  Task 
Group  MSG-068.  The  federation  is  intended  to  support  a  multi-national  distributed  advanced  technical  demonstration  of  MSG-068  results  at 
the  Interservice/Industry  Training,  Simulation  and  Education  Conference  (l/ITSEC)  held  in  Orlado  Florida,  USA  in  December  2010. 


Strategic  Theme 

Presenting  and  demonstrating  M&S  support  for  NATO  Future  Joint  Distributed  Traning  and  Exercises. 


Scope 

Demonstrate  the  main  results  of  MSG-068  task  group. 


Objectives 

•  Present  MSG-068  objectives,  activities,  main  results  and  recommendations 

•  Present  NETN  Federation  Architecture  and  FOM  Design 

•  Present  NETN  Infrastucture  Recommendations 

•  Demonstrate  (tecnical  demo)  a  distributed  NETN  federation  with  NATO  and  parner  national  systems 


Systems 


Name 

Description 

Purpose 

AV  System 

Audio  and  Video 

Audio  and  Video  Control 

Commander 

Federation  management 

Federation  Monitoring  and  Control 

Google  Earth 

Scenario  Viewer 

Situation  awareness  picture:  SITFOR, 

Police  and  civilian. 

EXCON/AAR  Online 

ICC 

Constructive  Air  Simulation  and  ICC  stimulation 

Recognized  Air  Picture  (RAP) 

JCATS 

Constructive  Joint  Simulation 

Joint  Land  Simulation 

JTLS 

Constructive  Joint  Simulation 

Joint  Simulation 
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KORA 

Constructive  Joint  Simulation 

Joint  Simulation 

ORQUE 

Constructive  Maritime  Simulation 

Maritime  Simulation  and  Air  Refueling 

PLEXcomm 

Radio  Simulation 

Tactical  and  Admin  Radio 

Simulation  Infrastructure 

Distributed  Simulation  Runtime  Infrastructure 

Simulation  Interoperability 

TYR 

Aggregate  Level  Constructive  Simulation 

Joint  Simulation. 

EXCON/AAR  Online 

VBS2 

First  Person  Virtual  Simulation 

Lower  tactical  and  UAV  simulation. 

Virtual  situation  awareness:  Land,  Air  och  Media 

VR-Forces 

Constructive  Simulation 

Joint  Simulation 

WAG RAM 

Constructive  Joint  Simulation 

Joint  Simulation 

System  Overview 


System  View 


NATO  Booth 


ORQ.UE 

Constructive 

Maritime 


WAG  RAM 
Constructive 
Land 


PLEXcomm 

Radio 


VBS2 
Visualization 
FPS 


IT C/ ICC 
Constructive 
AirC2 


JTLS 

Constructive 

Joint 


VR  Forces 
Constructive 
Joint 


PLEXcomm 

Radio 


MSG -068  T&I  Network  (NETN) 


Google  Earth 
Visualization 


Commander 

Federation 

Management 


PLEXcomm 

Radio 


JCATS 

Constructive 

Joint 


TYR 

Constructive 

Joint 


NETN 

Service 

Manager 


KORA 

Constructive 

Joint 


PLEXcomm 

Radio 


Other  Supporting  Software 


Tools  to  support  test,  integration  and  execution  of  the  fedration. 


Full  Name 

Version 

Description 

Pitch  Actors 

MSG-068 

CGF 

Pitch  Booster 

1.2 

Private  Simulation  Network  Overlay 

Pitch  NETN  Service  Manager 

MSG-068 

Test  tool  for  NETN  Consumer-Provider  Patterns 

Pitch  Recorder 

1.5 

Simulation  Traffic  Record,  Analysis  and  Playback 

Pitch  Visual  OMT  1516 

2.0 

HLA  Object  Model  Development  Tool 

Pitch  pRTI  1516 

4.2 

HLA  RTI 

The  following  tools  are  provided  by  SWE  to  all  participants  to  support  development,  test,  integration  and  execution  of  the  federation. 

•  Pitch  pRTI 

•  Pitch  Booster 

•  Pitch  Visual  OMT 

•  Pitch  Recorder 

•  Pitch  Commander 
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Instructions  for  obtaining  the  software  is  provided  by  FMV 


Scenario 

Scenarios  will  be  a  subset  of  the  MSG-068  Experimentation  Vignettes. 


Vignettes  for  main  presentation  (not  all  every  presentation) 


Incident 

Systems 

Demo 

UAV  Recce 

VBS2-UK,  JCATS 

RPR  and  NETN  classes 

Cruise  Missile 

Orque,  JCATS,  VBS2-UK 

RPR,  and  NETN  object  classes,  Detonation  Effects 

Airstrike 

JCATS,  JPECT,  VBS2-UK,  VBS2-NLD 

RPR,  and  NETN  object  classes,  Detonation  Effects 

Ground  Strike  with  CCA 

WAGRAM,  JCATS,  VR-Forces,  VBS2-UK,  TYR 

RPR  and  NETN  classes,  direct  and  indirect  fire 

Marine  Blocking  Position 

JCATS,  VBS2-UK 

RPR  and  NETN  classes,  indirect/direct  fire  and  detonation 

Additional  vignettes  prepared  for  demo  between  scheduled  events 


Incident 

Systems 

Demo 

Sealift 

Orque,  WAGRAM,  VR-Forces,  JTLS 

Convoy  Logistics  Pattern 

Air  Refuel 

ORQUE  ,  JTLS,  TYR 

Supply  Logistics  pattern 

Hostage  Evac 

KORA,  TYR 

Convoy  logistics  pattern 

MEDEVAC 

KORA,  VR-Forces 

Convoy  logistics  pattern 

Federation 

Simulation  Infrastructure 

The  federation  Runtime  Infrastructure  is  based  on  the  IEEE  1516-2010  (HLA  Evolved)  standard  service  API  for  distributed  simulation. 
Systems  using  older  HLA  standards  can  connect  using  provided  adapters. 


Simulation  Interface  Infrastructure 

HLA  IEEE  1516-2010 

pRTI  1516  v4.2 

HLA  IEEE  1516-2000 

pRTI  1 51 6  v4.2  and  1 51 6-2000  Adapter 

HLA  1.3 

pRTI  1 51 6  v4.2  and  HLA  1 .3  Adapter 

RTI  and  Federation  Settings 


Federation  Name 

NETN 

CRC  Name 

IITSEC_CRC 

NETN  Federates 


Full  Name 

Federate  Name 

Federate  Type 

HLA  Interface 

Federate  Instances 

ALLIGATOR 

ORQUE&WAGRAM 

ALLIGATOR 

IEEE  1516-2010 

1 

Pitch  Commander  Agent 

Commander 

Commander  Agent 

IEEE  1516-2010 

1 

ITC  Flames 

ITC  Flames 

ITC  Flames 

HLA  1.3 

1 

JCATS  Server 

JCATS 

JLVC 

IEEE  1516-2010 

1 

JTLS  Server 

JTLS 

JTLS 

IEEE  1516-2010 

1 
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KORA 

KORA 

KORA 

IEEE  1516-2010 

1 

LVC  Game 

VBS2 

LVC  Game 

IEEE  1516-2010 

1 

PLEXcomm 

PLEXcomm 

PLEXcomm 

HLA  1.3 

10 

Pitch  GE  Adapter 

Google  Earth 

GE  Adapter 

IEEE  1516-2010 

1 

CATS  TYR  Client 

TYR  Client 

TYR  Client 

IEEE  1516-2010 

1 

CATS  TYR  Server 

TYR  Server 

TYR  Server 

IEEE  1516-2010 

1 

VR-Forces 

VR-Forces 

VR-Forces 

IEEE  1516-2010 

1 

For  test  and  integration  the  following  federates  will  also  join  the  federation. 


Full  Name 

Federate  Name 

Federate  Type 

HLA  Interface 

Federate  Instances 

Pitch  Actors 

Actors 

Actors 

IEEE  1516-2010 

1 

Pitch  NETN  Service  Manager 

Service  Manager 

NETN  Service  Manager 

IEEE  1516-2010 

1 

Pitch  Recorder 

Pitch  Recorder 

Recorder 

IEEE  1516-2010 

1 

Lollipop 


Federation  View 


Booth  Layout 

Show  Floorplan 
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Detailed  Booth  Layout 
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Network 


Name  IP 

Display  Control  Laptop 

192.168.10.07 

Google  Earth  Laptop 

192.168.10.11 

RTI  and  Booster  Laptop 

192.168.10.12  + Public  IP 

TYR  Server  Laptop 

192.168.10.13 

TYR  Client  Laptop 

192.168.10.14 

JCATS  Server  Laptop 

192.168.10.15 

JCATS  Client  Laptop 

192.168.10.16 

ITC  Laptop 

192.168.10.17 

ICC  Laptop 

192.168.10.18 

ORQUE  Laptop 

192.168.10.19 

WAG  RAM  Laptop 

192.168.10.20 

ALLIGATOR  Laptop 

192.168.10.21 

JTLS  Client  Laptop 

192.168.10.22 

JTLS  Server  Laptop 

192.168.10.23 

VBS2  UK  Laptop 

192.168.10.24 

LVC  Game  Laptop 

192.168.10.25 

Booster  "IITSEC"  running  on  192.168.10.12 


192.168.10.3-10  Reserved  for  SAF  Demonstration 


Remote  Sites  and  Systems 


Site 

Booster 

Systems 

IABG,  Ottobrunn,  DEU 

84.11.17.135:8686 

KORA 

MoD,  Madrid,  ESP 

88.30.61.95:8686 

VR-Forces 

JFTC,  Bydgoszcz,  POL 

81.15.244.88:8686 

Artifex,  Budapest,  HUN 

81.183.210.28:8686 

TNO,  The  Hague, NLD 

195.169.128.61:8686 

NC3A,  The  Hague, NLD 

195.169.118.98:8686 

FMV,  Stockholm,  SWE 

192.165.65.207:8686 

Pitch,  Linkoping,  SWE 

80.252.168.222:8686 

DGA,  Paris,  FRA 

194.254.107.30:8687 

R&A,  Monterey,  CA 

216.228.3.210:8686 

PLEXSYS,  Camas, WA 

173.164.66.89:8688 

Calytrix,  Perth,  AUS 

116.212.205.222:8686 

IITSEC1 0,  Orlando,  FL 

TBD 

TYR,  JCATS,  VBS2,  JTLS,  ORQUE,  WAGRAM,  ITC/ICC 
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I/ITSEC2010 
Network  Diagram 
10/18/2010 


VLAN:  192.168.10.0/24 


Audio  and  Video 

Video 


•  16x16  Video  Switch  Provided  by  JFCOM 


Name 

Video  Switch  Input  # 

Video  Output  # 

JCATS  Client  Laptop 

2 

Google  Earth  Laptop 

7 

TYR  Client  Laptop 

8 

ICC  Laptop 

9 

ITC  Laptop 

10 

VBS2  UK  Laptop 

12 

JTLS  Client  Laptop 

13 

WAG  RAM  Laptop 

14 

ORQUE  Laptop 

16 

External  Monitor  NATO  Center 

1 

External  Monitor  NATO  Left 

2 

External  Monitor  NATO  Right 

3 

External  Monitor  FedExCtrl 

5 

Display  Control  Laptop 

16x16  Video  Switch 

Input  10-16  reserved  for  NATO  MSG-068  Demonstration  Systems. 
Output  10-16  reserved  for  NATO  MSG-068  Demonstration  Systems 
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Audio 


•  PA  System  provided  by  JFCOM 
PLEXcomm  audio  out  O  External  Speakers 


Operators 

System  Operators  and  Technical  POC 


Name 

Operator 

Technical  POC 

AV  System 

Per-Philip  Sollin 

Jim  Janele 

Commander 

Bjorn  Lofstrand 

Per-Philip  Sollin 

Google  Earth 

Bjorn  Lofstrand 

Bjorn  Lofstrand 

ICC 

Clive  Wood 

Clive  Wood 

JCATS 

Thierry  Grom 

Thierry  Grom 

JTLS 

KORA 

Michael  Wolf-Bolle 

ORQUE 

PLEXcomm 

All  Operators 

Jamie  Boulet 

Simulation  Infrastructure 

Per-Philip  Sollin 

TYR 

Max  Karlstrom 

Max  Karlstrom 

VBS2 

Caroline  Pettitt-Morris 

Caroline  Pettitt-Morris 

VR-Forces 

Patricio  Jimenez 

Patricio  Jimenez 

WAG RAM 

Appendix 

Appendix  1  -  Systems 


Name 

Full  Name 

Version 

Commercial 

POC 

Technical 

POC 

Operator 

Description 

Purpose 

AV  System 

AV  System 

Jim  Janele 

Jim  Janele 

Per-Philip 

Sollin 

Audio  and  Video 

Audio  and  Video 

Control 

Commander 

Pitch 

Commander 

2.2.0 

Bjorn 

Lofstrand 

Per-Philip 

Sollin 

Bjorn 

Lofstrand 

Federation 

management 

Federation  Monitoring 
and  Control 

Google  Earth 

Google  Earth 
PRO 

5.2.1.1588 

Bjorn 

Lofstrand 

Bjorn 

Lofstrand 

Bjorn 

Lofstrand 

Scenario  Viewer 

Situation  awareness 
picture:  SITFOR, 

Police  and  civilian. 
EXCON/AAR  Online 

ICC 

ICC 

Clive  Wood 

Clive  Wood 

Constructive  Air 
Simulation  and  ICC 
stimulation 

Recognized  Air  Picture 
(RAP) 

JCATS 

JCATS 

Server 

Amy  Grom 

Thierry 

Grom 

Thierry 

Grom 

Constructive  Joint 
Simulation 

Joint  Land  Simulation 

JTLS 

JTLS  Server 

Constructive  Joint 
Simulation 

Joint  Simulation 

KORA 

KORA 

Karl-Fleinz 

Neumann 

Michael 

Wolf-Bolle 

Constructive  Joint 
Simulation 

Joint  Simulation 
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ORQUE 

ORQUE 

Jose  Ruiz 

Constructive  Maritime 
Simulation 

Maritime  Simulation 
and  Air  Refueling 

PLEXcomm 

PLEXcomm 

3.0 

Jamie 

Boulet 

All 

Operators 

Radio  Simulation 

Tactical  and  Admin 
Radio 

Simulation 

Infrastructure 

Simulation 

Infrastructure 

Bjorn 

Lofstrand 

Per-Philip 

Sollin 

Distributed  Simulation 
Runtime  Infrastructure 

Simulation 

Interoperability 

TYR 

CATS  TYR 
Server 

3.2 

Torsten 

Bernstrom 

Max 

Karlstrom 

Max 

Karlstrom 

Aggregate  Level 
Constructive 

Simulation 

Joint  Simulation. 
EXCON/AAR  Online 

VBS2 

Virtual 

Battlespace 

2 

Caroline 

Pettitt-Morris 

Caroline 

Pettitt-Morris 

Caroline 

Pettitt-Morris 

First  Person  Virtual 
Simulation 

Lower  tactical  and 

UAV  simulation. 

Virtual  situation 
awareness:  Land,  Air 
och  Media 

VR-Forces 

VR-Forces 

Patricio 

Jimenez 

Patricio 

Jimenez 

Patricio 

Jimenez 

Constructive 

Simulation 

Joint  Simulation 

WAG RAM 

WAG RAM 

Jose  Ruiz 

Constructive  Joint 
Simulation 

Joint  Simulation 

AV  System 


Name 

AV  System 

Full  Name 

AV  System 

Commercial  POC 

Jim  Janele 

Technical  POC 

Jim  Janele 

Operator 

Per-Philip  Sollin 

Description 

Audio  and  Video 

Purpose 

Audio  and  Video  Control 

AV  Hardware 


Name 

Owner 

Tech  POC 

Location 

JTLS  Client  Laptop 

JWC 

Andy  Brown 

NATO  Booth 

ORQUE  Laptop 

DGA 

Jose  Ruiz 

NATO  Booth 

External  Monitor  NATO  Right 

JFCOM 

Jim  Janele 

NATO  Booth 

Display  Control  Laptop 

Pitch 

Per-Philip  Sollin 

SAF  Booth 

Google  Earth  Laptop 

FMV 

Bjorn  Lofstrand 

SAF  Booth 

ICC  Laptop 

NC3A 

Clive  Wood 

NATO  Booth 

JCATS  Client  Laptop 

JFCOM 

Thierry  Grom 

SAF  Booth 

TYR  Client  Laptop 

FMV 

Max  Karlstrom 

SAF  Booth 

WAG  RAM  Laptop 

DGA 

Jose  Ruiz 

NATO  Booth 

ITC  Laptop 

NC3A 

Clive  Wood 

NATO  Booth 

External  Monitor  NATO  Center 

JFCOM 

Jim  Janele 

NATO  Booth 

External  Monitor  NATO  Left 

JFCOM 

Jim  Janele 

NATO  Booth 

External  Monitor  FedExCtrl 

JFCOM 

Jim  Janele 

SAF  Booth 

VBS2  UK  Laptop 

DSTL 

Caroline  Pettitt-Morris 

NATO  Booth 

16x16  Video  Switch 

JFCOM 

Jim  Janele 

SAF  Storage 

Software 
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Full  Name  Version  Description 


Commander 


Name 

Commander 

Full  Name 

Pitch  Commander 

Version 

2.2.0 

Commercial  POC 

Bjorn  Lofstrand 

Technical  POC 

Per-Philip  Sollin 

Operator 

Bjorn  Lofstrand 

Description 

Federation  management 

Purpose 

Federation  Monitoring  and  Control 

Hardware 


Name 

Owner 

Tech  POC 

Location 

Google  Earth  Laptop 

FMV 

Bjorn  Lofstrand 

SAF  Booth 

Software 


Full  Name 

Version 

Description 

Pitch  Commander 

2.2.0 

Federation  management 

Pitch  Commander  Agent 

2.2.0 

Agent  for  monitoring  and  control 

Google  Earth 


Name 

Google  Earth 

Full  Name 

Google  Earth  PRO 

Version 

5.2.1.1588 

Commercial  POC 

Bjorn  Lofstrand 

Technical  POC 

Bjorn  Lofstrand 

Operator 

Bjorn  Lofstrand 

Description 

Scenario  Viewer 

Purpose 

Situation  awareness  picture:  SITFOR, 

Police  and  civilian. 

EXCON/AAR  Online 

Hardware 


Name 

Owner 

Tech  POC 

Location 

Google  Earth  Laptop 

FMV 

Bjorn  Lofstrand 

SAF  Booth 

Software 


Full  Name 

Version 

Description 

Google  Earth  PRO 

5.2.1.1588 

Scenario  Viewer 

Pitch  GE  Adapter 

1.4 

Google  Earth  Adapter  for  HLA 

ICC 
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Name 

ICC 

Full  Name 

ICC 

Version 

Description 

Constructive  Air  Simulation  and  ICC  stimulation 

Federation 


Purpose 

Recognized  Air  Picture  (RAP) 

Commercial  POC 

Technical  POC 

Clive  Wood 

Operator 

Clive  Wood 

Hardware 


Name 

Owner 

Tech  POC 

Location 

ICC  Laptop 

NC3A 

Clive  Wood 

NATO  Booth 

ITC  Laptop 

NC3A 

Clive  Wood 

NATO  Booth 

Software 


Full  Name 

Version 

Description 

ICC 

Constructive  Air  Simulation  and  ICC  stimulation 

ITC  Flames 

Constructive  Air  Simulation  and  ICC  stimulation 

Integration  Support 


Name 

Integration  Support 

Full  Name 

Integration  Support 

Version 

Commercial  POC 

Technical  POC 

Lennart  Olsson 

Operator 

Description 

Supporting  tools  for  test  and  integration 

Purpose 

Integration  Support 

Hardware 


Name 

Owner 

Tech  POC 

Location 

RTI  and  Booster  Laptop 

FMV 

Lennart  Olsson 

SAF  Booth 

Software 


Full  Name 

Version 

Description 

Pitch  Actors 

MSG-068 

CGF 

Pitch  NETN  Service  Manager 

MSG-068 

Test  tool  for  NETN  Consumer-Provider  Patterns 

Pitch  Recorder 

1.5 

Simulation  Traffic  Record,  Analysis  and  Playback 

Pitch  Visual  OMT  1516 

2.0 

HLA  Object  Model  Development  Tool 

JCATS 
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Name 

JCATS 

Full  Name 

JCATS  Server 

Version 

Commercial  POC 

Amy  Grom 

Technical  POC 

Thierry  Grom 

Operator 

Thierry  Grom 

Description 

Constructive  Joint  Simulation 

Purpose 

Joint  Land  Simulation 

Federation 


Federate  Name 

JCATS 

Federate  Type 

JLVC 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

Hardware 


Name 

Owner 

Tech  POC 

Location 

JCATS  Client  Laptop 

JFCOM 

Thierry  Grom 

SAF  Booth 

JCATS  Server  Laptop 

JFCOM 

Thierry  Grom 

SAF  Storage 

Software 


Full  Name 

Version 

Description 

JCATS  Server 

Constructive  Joint  Simulation 

JCATS  Client 

JCATS  Client 

JTLS 


Name 

JTLS 

Full  Name 

JTLS  Server 

Version 

Commercial  POC 

Technical  POC 

Operator 

Description 

Constructive  Joint  Simulation 

Purpose 

Joint  Simulation 

Federation 


Federate  Name 

JTLS 

Federate  Type 

JTLS 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

Hardware 
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Name 

Owner 

Tech  POC 

Location 

JTLS  Client  Laptop 

JWC 

Andy  Brown 

NATO  Booth 

JTLS  Server  Laptop 

JWC 

Andy  Brown 

SAF  Storage 

Software 


Full  Name 

Version 

Description 

JTLS  Server 

Constructive  Joint  Simulation 

JTLS  Client 

JTLS  Client 

KORA 


Name 

KORA 

Full  Name 

KORA 

Version 

Commercial  POC 

Karl-Heinz  Neumann 

Technical  POC 

Michael  Wolf-Bolle 

Operator 

Description 

Constructive  Joint  Simulation 

Purpose 

Joint  Simulation 

Federation 


Federate  Name 

KORA 

Federate  Type 

KORA 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

Hardware 

Remote  Site 


System 

KORA 

Owner 

IABG 

Location 

Ottobrunn  Site 

IP 

Remote  Site 

Tech  POC 

Karl-Heinz  Neumann 

Video  Switch  Input  # 

Video  Out  Resolution 

ORQUE 


Name 

ORQUE 

Full  Name 

ORQUE 

Version 

Commercial  POC 

Jose  Ruiz 

Technical  POC 

Operator 
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Description 

Constructive  Maritime  Simulation 

Purpose 

Maritime  Simulation  and  Air  Refueling 

Hardware 


Name 

Owner 

Tech  POC 

Location 

ORQUE  Laptop 

DGA 

Jose  Ruiz 

NATO  Booth 

ALLIGATOR  Laptop 

DGA 

Jose  Ruiz 

NATO  Booth 

Software 


Full  Name 

Version 

Description 

ORQUE 

Constructive  Maritime  Simulation 

ALLIGATOR 

ORQUE  and  WAGRAM  bridge  to  NETN 

PLEXcomm 


Name 

PLEXcomm 

Full  Name 

PLEXcomm 

Version 

3.0 

Commercial  POC 

Technical  POC 

Jamie  Boulet 

Operator 

All  Operators 

Description 

Radio  Simulation 

Purpose 

Tactical  and  Admin  Radio 

Federation 


Federate  Name 

PLEXcomm 

Federate  Type 

PLEXcomm 

HLA  Interface 

HLA  1.3 

Federate  Instances 

10 

Hardware 


Name 

Owner 

Tech  POC 

Location 

JTLS  Client  Laptop 

JWC 

Andy  Brown 

NATO  Booth 

LVC  Game  Laptop 

DSTL 

Caroline  Pettitt-Morris 

NATO  Booth 

Display  Control  Laptop 

Pitch 

Per-Philip  Sollin 

SAF  Booth 

Google  Earth  Laptop 

FMV 

Bjorn  Lofstrand 

SAF  Booth 

JCATS  Client  Laptop 

JFCOM 

Thierry  Grom 

SAF  Booth 

RTI  and  Booster  Laptop 

FMV 

Lennart  Olsson 

SAF  Booth 

TYR  Client  Laptop 

FMV 

Max  Karlstrom 

SAF  Booth 

ITC  Laptop 

NC3A 

Clive  Wood 

NATO  Booth 

KORA 

IABG 

Karl-Heinz  Neumann 

Ottobrunn  Site 

VR-Forces 

ESP  MoD 

Patricio  Jimenez 

Madrid  Site 

Software 
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Full  Name 

Version 

Description 

PLEXcomm 

3.0 

Radio  Simulation 

Simulation  Infrastructure 


Name 

Simulation  Infrastructure 

Full  Name 

Simulation  Infrastructure 

Commercial  POC 

Bjorn  Lofstrand 

Technical  POC 

Per-Philip  Sollin 

Description 

Distributed  Simulation  Runtime  Infrastructure 

Purpose 

Simulation  Interoperability 

Hardware 


Name 

Owner 

Tech  POC 

Location 

RTI  and  Booster  Laptop 

FMV 

Lennart  Olsson 

SAF  Booth 

Software 


Full  Name 

Version 

Description 

Pitch  Booster 

1.2 

Private  Simulation  Network  Overlay 

Pitch  pRTI  1516 

4.2 

HLA  RTI 

TYR 


Name 

TYR 

Full  Name 

CATS  TYR  Server 

Version 

3.2 

Commercial  POC 

Torsten  Bernstrom 

Technical  POC 

Max  Karlstrom 

Operator 

Max  Karlstrom 

Description 

Aggregate  Level  Constructive  Simulation 

Purpose 

Joint  Simulation. 

EXCON/AAR  Online 

Federation 


Federate  Name 

TYR  Server 

Federate  Type 

TYR  Server 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

Hardware 


Name  Owner  Tech  POC  Location 


Software 


Full  Name 

Version 

Description 

CATS  TYR  Server 

3.2 

Aggregate  Level  Constructive  Simulation 
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CATS  TYR  Client 


3.2 


TYR  Client  Federate 


WAGRAM 


Name 

WAGRAM 

Full  Name 

WAGRAM 

Version 

Commercial  POC 

Jose  Ruiz 

Technical  POC 

Operator 

Description 

Constructive  Joint  Simulation 

Purpose 

Joint  Simulation 

Hardware 


Name 

Owner 

Tech  POC 

Location 

ALLIGATOR  Laptop 

DGA 

Jose  Ruiz 

NATO  Booth 

WAGRAM  Laptop 

DGA 

Jose  Ruiz 

NATO  Booth 

Software 


Full  Name 

Version 

Description 

WAGRAM 

Constructive  Joint  Simulation 

ALLIGATOR 

ORQUE  and  WAGRAM  bridge  to  NETN 

VBS2 


Name 

VBS2 

Full  Name 

Virtual  Battlespace  2 

Version 

Commercial  POC 

Caroline  Pettitt-Morris 

Technical  POC 

Caroline  Pettitt-Morris 

Operator 

Caroline  Pettitt-Morris 

Description 

First  Person  Virtual  Simulation 

Purpose 

Lower  tactical  and  UAV  simulation. 

Virtual  situation  awareness:  Land,  Air  och  Media 

Hardware 


Name 

Owner 

Tech  POC 

Location 

LVC  Game  Laptop 

DSTL 

Caroline  Pettitt-Morris 

NATO  Booth 

VBS2  UK  Laptop 

DSTL 

Caroline  Pettitt-Morris 

NATO  Booth 

Software 


Full  Name 

Version 

Description 

LVC  Game 

3.1.921.27503 

VBS2  Bridge  to  HLA 

Virtual  Battlespace  2 

First  Person  Virtual  Simulation 
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VR-Forces 


Name 

VR-Forces 

Full  Name 

VR-Forces 

Version 

Commercial  POC 

Patricio  Jimenez 

Technical  POC 

Patricio  Jimenez 

Operator 

Patricio  Jimenez 

Description 

Constructive  Simulation 

Purpose 

Joint  Simulation 

Federation 


Federate  Name 

VR-Forces 

Federate  Type 

VR-Forces 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

Hardware 

Remote  Site 


System 

VR-Forces 

Owner 

ESP  MoD 

Location 

Madrid  Site 

IP 

Remote  Site 

Tech  POC 

Patricio  Jimenez 

Video  Switch  Input  # 

Video  Out  Resolution 

Appendix  2  -  Supporting  Software 


Name 

Full  Name 

Version 

System 

Description 

ALLIGATOR 

ALLIGATOR 

ORQUE,  WAGRAM 

ORQUE  and  WAGRAM  bridge  to  NETN 

Actors 

Pitch  Actors 

MSG-068 

Integration  Support 

CGF 

Booster 

Pitch  Booster 

1.2 

Simulation 

Infrastructure 

Private  Simulation  Network  Overlay 

Commander  Agent 

Pitch  Commander  Agent 

2.2.0 

Commander 

Agent  for  monitoring  and  control 

ITC 

ITC  Flames 

ICC 

Constructive  Air  Simulation  and  ICC 
stimulation 

JCATS  Client 

JCATS  Client 

JCATS 

JCATS  Client 

JTLS  Client 

JTLS  Client 

JTLS 

JTLS  Client 

LVC  Game 

LVC  Game 

3.1.921.27503 

VBS2 

VBS2  Bridge  to  HLA 

NETN  Service 

Manager 

Pitch  NETN  Service 
Manager 

MSG-068 

Integration  Support 

Test  tool  for  NETN  Consumer-Provider 
Patterns 

Pitch  GE  Adapter 

Pitch  GE  Adapter 

1.4 

Google  Earth 

Google  Earth  Adapter  for  HLA 

Recorder 

Pitch  Recorder 

1.5 

Integration  Support 

Simulation  Traffic  Record,  Analysis  and 
Playback 
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TYR  Client 

CATS  TYR  Client 

3.2 

TYR 

TYR  Client  Federate 

Visual  OMT 

Pitch  Visual  OMT  1516 

2.0 

Integration  Support 

HLA  Object  Model  Development  Tool 

pRTI  1516 

Pitch  pRTI  1516 

4.2 

Simulation 

Infrastructure 

HLA  RTI 

Actors 


Name 

Actors 

System 

Integration  Support 

Full  Name 

Pitch  Actors 

Version 

MSG-068 

Commercial  POC 

Technical  POC 

Lennart  Olsson 

Operator 

Lennart  Olsson 

Description 

CGF 

Federation 


Federate  Name 

Actors 

Federate  Type 

Actors 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

ALLIGATOR 


Name 

ALLIGATOR 

System 

ORQUE,  WAGRAM 

Full  Name 

ALLIGATOR 

Version 

Commercial  POC 

Technical  POC 

Operator 

Description 

ORQUE  and  WAGRAM  bridge  to  NETN 

Federation 


Federate  Name 

ORQUE&WAGRAM 

Federate  Type 

ALLIGATOR 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

Booster 


Name 

Booster 

Full  Name 

Pitch  Booster 

Version 

1.2 

System 

Simulation  Infrastructure 
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Commercial  POC 

Bjorn  Lofstrand 

Technical  POC 

Per-Philip  Sollin 

Operator 

Lennart  Olsson 

Description 

Private  Simulation  Network  Overlay 

Purpose 

Simulation  Interoperability 

Commander  Agent 


Name 

Commander  Agent 

System 

Commander 

Full  Name 

Pitch  Commander  Agent 

Federate  Name 

Commander 

Federate  Type 

Commander  Agent 

Version 

2.2.0 

Commercial  POC 

Bjorn  Lofstrand 

Technical  POC 

Bjorn  Lofstrand 

Operator 

Bjorn  Lofstrand 

Description 

Agent  for  monitoring  and  control 

Federation 


Federate  Name 

Commander 

Federate  Type 

Commander  Agent 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

GE  Adapter 


Name 

Pitch  GE  Adapter 

System 

Google  Earth 

Full  Name 

Pitch  GE  Adapter 

Federate  Name 

Google  Earth 

Federate  Type 

GE  Adapter 

Version 

1.4 

Commercial  POC 

Bjorn  Lofstrand 

Technical  POC 

Bjorn  Lofstrand 

Operator 

Bjorn  Lofstrand 

Description 

Google  Earth  Adapter  for  HLA 

Federation 


Federate  Name 

Google  Earth 

Federate  Type 

GE  Adapter 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 
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ITC 


Name 

ITC 

Full  Name 

ITC  Flames 

Version 

System 

ICC 

Commercial  POC 

Clive  Wood 

Technical  POC 

Clive  Wood 

Operator 

Clive  Wood/Richard  Hall 

Description 

Constructive  Air  Simulation  and  ICC  stimulation 

Federation 


Federate  Name 

ITC  Flames 

Federate  Type 

ITC  Flames 

HLA  Interface 

HLA  1.3 

Federate  Instances 

1 

JCATS  Client 


Name 

JCATS  Client 

System 

JCATS 

Full  Name 

JCATS  Client 

Version 

Commercial  POC 

Technical  POC 

Operator 

Description 

JCATS  Client 

JTLS  Client 


Name 

JTLS  Client 

System 

JTLS 

Full  Name 

JTLS  Client 

Version 

Commercial  POC 

Technical  POC 

Operator 

Description 

JTLS  Client 

LVC  Game 

Name 

LVC  Game 

System 

VBS2 

Full  Name 

LVC  Game 

Federate  Name 

VBS2 
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Federate  Type 

LVC  Game 

Version 

3.1.921.27503 

Commercial  POC 

Technical  POC 

Caroline  Pettitt-Morris 

Operator 

Description 

VBS2  Bridge  to  HLA 

Federation 


Federate  Name 

VBS2 

Federate  Type 

LVC  Game 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

NETN  Service  Manager 


Name 

NETN  Service  Manager 

System 

Integration  Support 

Full  Name 

Pitch  NETN  Service  Manager 

Version 

MSG-068 

Commercial  POC 

Technical  POC 

Lennart  Olsson 

Operator 

Lennart  Olsson 

Description 

Test  tool  for  NETN  Consumer-Provider  Patterns 

Federation 


Federate  Name 

Service  Manager 

Federate  Type 

NETN  Service  Manager 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

pRT1 1516 


Name 

pRTI  1516 

Full  Name 

Pitch  pRTI  1516 

Version 

4.2 

System 

Simulation  Infrastructure 

Commercial  POC 

Bjorn  Lofstrand 

Technical  POC 

Per-Philip  Sollin 

Operator 

Lennart  Olsson 

Description 

HLA  RTI 

Recorder 


Name 


Recorder 
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System 

Integration  Support 

Full  Name 

Pitch  Recorder 

Version 

1.5 

Commercial  POC 

Bjorn  Lofstrand 

Technical  POC 

Lennart  Olsson 

Operator 

Lennart  Olsson 

Description 

Simulation  Traffic  Record,  Analysis  and  Playback 

Federation 


Federate  Name 

Pitch  Recorder 

Federate  Type 

Recorder 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

TYR  Client 


Name 

TYR  Client 

System 

TYR 

Full  Name 

CATS  TYR  Client 

Version 

3.2 

Commercial  POC 

Torsten  Bernstrom 

Technical  POC 

Max  Karlstrom 

Operator 

Max  Karlstrom 

Description 

TYR  Client  Federate 

Federation 


Federate  Name 

TYR  Client 

Federate  Type 

TYR  Client 

HLA  Interface 

IEEE  1516-2010 

Federate  Instances 

1 

Visual  OMT 


Name 

Visual  OMT 

System 

Integration  Support 

Full  Name 

Pitch  Visual  OMT  1516 

Version 

2.0 

Commercial  POC 

Bjorn  Lofstrand 

Technical  POC 

Lennart  Olsson 

Operator 

Lennart  Olsson 

Description 

HLA  Object  Model  Development  Tool 

Appendix  3  -  Hardware 
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Name 

System 

Owner 

Location 

IP 

Tech  POC 

Display  Control  Laptop 

AV  System,  PLEXcomm 

Pitch 

SAF  Booth 

192.168.10.07 

Per-Philip  Sollin 

Google  Earth  Laptop 

Google  Earth,  PLEXcomm 

FMV 

SAF  Booth 

192.168.10.11 

Bjorn  Lofstrand 

RTI  and  Booster  Laptop 

Simulation  Infrastructure,  Integration  Support, 
PLEXcomm 

FMV 

SAF  Booth 

192.168.10.12  + 
Public  IP 

Lennart  Olsson 

TYR  Server  Laptop 

TYR 

FMV 

SAF 

Storage 

192.168.10.13 

Max  Karlstrom 

TYR  Client  Laptop 

TYR,  PLEXcomm 

FMV 

SAF  Booth 

192.168.10.14 

Max  Karlstrom 

JCATS  Server  Laptop 

JCATS 

JFCOM 

SAF 

Storage 

192.168.10.15 

Thierry  Grom 

JCATS  Client  Laptop 

JCATS,  PLEXcomm 

JFCOM 

SAF  Booth 

192.168.10.16 

Thierry  Grom 

ITC  Laptop 

ICC,  PLEXcomm 

NC3A 

NATO 

Booth 

192.168.10.17 

Clive  Wood 

ICC  Laptop 

ICC 

NC3A 

NATO 

Booth 

192.168.10.18 

Clive  Wood 

ORQUE  Laptop 

ORQUE 

DGA 

NATO 

Booth 

192.168.10.19 

Jose  Ruiz 

WAG  RAM  Laptop 

WAG RAM 

DGA 

NATO 

Booth 

192.168.10.20 

Jose  Ruiz 

ALLIGATOR  Laptop 

ORQUE,  WAGRAM 

DGA 

NATO 

Booth 

192.168.10.21 

Jose  Ruiz 

JTLS  Client  Laptop 

JTLS,  PLEXcomm 

JWC 

NATO 

Booth 

192.168.10.22 

Andy  Brown 

JTLS  Server  Laptop 

JTLS 

JWC 

SAF 

Storage 

192.168.10.23 

Andy  Brown 

VBS2  UK  Laptop 

VBS2 

DSTL 

NATO 

Booth 

192.168.10.24 

Caroline 

Pettitt-Morris 

LVC  Game  Laptop 

VBS2,  PLEXcomm 

DSTL 

NATO 

Booth 

192.168.10.25 

Caroline 

Pettitt-Morris 

KORA 

KORA 

IABG 

Ottobrunn 

Site 

Remote  Site 

Karl-Heinz 

Neumann 

VR-Forces 

VR-Forces 

ESP 

MoD 

Madrid 

Site 

Remote  Site 

Patricio  Jimenez 

External  Monitor  NATO 
Right 

AV  System 

JFCOM 

NATO 

Booth 

Jim  Janele 

External  Monitor  NATO 
Center 

AV  System 

JFCOM 

NATO 

Booth 

Jim  Janele 

External  Monitor  NATO 
Left 

AV  System 

JFCOM 

NATO 

Booth 

Jim  Janele 

External  Monitor 
FedExCtrl 

AV  System 

JFCOM 

SAF  Booth 

Jim  Janele 

16x16  Video  Switch 

AV  System 

JFCOM 

SAF 

Storage 

Jim  Janele 

16x16  Video  Switch 


Name 

16x16  Video  Switch 

System 

AV  System 

Owner 

JFCOM 

Location 

SAF  Storage 

Tech  POC 

Jim  Janele 
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ALLIGATOR  Laptop 


Name 

ALLIGATOR  Laptop 

System 

ORQUE,  WAGRAM 

Owner 

DGA 

Location 

NATO  Booth 

IP 

192.168.10.21 

Tech  POC 

Jose  Ruiz 

Video  Switch  Input  # 

Video  Out  Resolution 

Display  Control  Laptop 


Name 

Display  Control  Laptop 

System 

AV  System,  PLEXcomm 

Owner 

Pitch 

Location 

SAF  Booth 

IP 

192.168.10.07 

Tech  POC 

Per-Philip  Sollin 

External  Monitor  FedExCtrl 


Name 

External  Monitor  FedExCtrl 

System 

AV  System 

Owner 

JFCOM 

Location 

SAF  Booth 

Tech  POC 

Jim  Janele 

Video  Output  # 

5 

External  Monitor  NATO  Center 

Name 

External  Monitor  NATO  Center 

System 

AV  System 

Owner 

JFCOM 

Description 

60"  Plasma 

Location 

NATO  Booth 

Tech  POC 

Jim  Janele 

Video  Output  # 

1 

External  Monitor  NATO  Left 

Name 

External  Monitor  NATO  Left 

System 

AV  System 

Owner 

JFCOM 

Location 

NATO  Booth 

Tech  POC 

Jim  Janele 

F  -  26 


RTO-TR-MSG-068 


Video  Output  # 
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External  Monitor  NATO  Right 


Name 

External  Monitor  NATO  Right 

System 

AV  System 

Owner 

JFCOM 

Location 

NATO  Booth 

Tech  POC 

Jim  Janele 

Video  Output  # 

3 

Google  Earth  Laptop 


Name 

Google  Earth  Laptop 

System 

Google  Earth,  PLEXcomm 

Owner 

FMV 

Location 

SAF  Booth 

IP 

192.168.10.11 

Tech  POC 

Bjorn  Lofstrand 

Video  Switch  Input  # 

7 

Video  Out  Resolution 

ICC  Laptop 

Name 

ICC  Laptop 

System 

ICC 

Owner 

NC3A 

Location 

NATO  Booth 

IP 

192.168.10.18 

Tech  POC 

Clive  Wood 

Video  Switch  Input  # 

9 

Video  Out  Resolution 

ITC  Laptop 


Name 

ITC  Laptop 

System 

ICC,  PLEXcomm 

Owner 

NC3A 

Location 

NATO  Booth 

IP 

192.168.10.17 

Tech  POC 

Clive  Wood 

Video  Switch  Input  # 

10 

Video  Out  Resolution 

JCATS  Client  Laptop 
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Name 

JCATS  Client  Laptop 

System 

JCATS,  PLEXcomm 

Owner 

JFCOM 

Location 

SAF  Booth 

IP 

192.168.10.16 

Tech  POC 

Thierry  Grom 

Video  Switch  Input  # 

2 

Video  Out  Resolution 

JCATS  Server  Laptop 


Name 

JCATS  Server  Laptop 

System 

JCATS 

Owner 

JFCOM 

Location 

SAF  Storage 

IP 

192.168.10.15 

Tech  POC 

Thierry  Grom 

JTLS  Client  Laptop 


Name 

JTLS  Client  Laptop 

System 

JTLS,  PLEXcomm 

Owner 

JWC 

Location 

NATO  Booth 

IP 

192.168.10.22 

Tech  POC 

Andy  Brown 

Video  Switch  Input  # 

13 

Video  Out  Resolution 

JTLS  Server  Laptop 


Name 

JTLS  Server  Laptop 

System 

JTLS 

Owner 

JWC 

Location 

SAF  Storage 

IP 

192.168.10.23 

Tech  POC 

Andy  Brown 

Video  Switch  Input  # 

Video  Out  Resolution 

LVC  Game  Laptop 


Name 

LVC  Game  Laptop 

System 

VBS2,  PLEXcomm 

Owner 

DSTL 

F  -  28 
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Location 

NATO  Booth 

IP 

192.168.10.25 

Tech  POC 

Caroline  Pettitt-Morris 

Video  Switch  Input  # 

Video  Out  Resolution 

ORQUE  Laptop 


Name 

ORQUE  Laptop 

System 

ORQUE 

Owner 

DGA 

Location 

NATO  Booth 

IP 

192.168.10.19 

Tech  POC 

Jose  Ruiz 

Video  Switch  Input  # 

16 

Video  Out  Resolution 

RTI  and  Booster  Laptop 


Name 

RTI  and  Booster  Laptop 

System 

Simulation  Infrastructure,  Integration  Support,  PLEXcomm 

Owner 

FMV 

Location 

SAF  Booth 

IP 

192.168.10.12  + Public  IP 

Tech  POC 

Lennart  Olsson 

TYR  Client  Laptop 


Name 

TYR  Client  Laptop 

System 

TYR,  PLEXcomm 

Owner 

FMV 

Location 

SAF  Booth 

IP 

192.168.10.14 

Tech  POC 

Max  Karlstrom 

Video  Switch  Input  # 

8 

Video  Out  Resolution 

TYR  Server  Laptop 


Name 

TYR  Server  Laptop 

System 

TYR 

Owner 

FMV 

Location 

SAF  Storage 

IP 

192.168.10.13 

Tech  POC 

Max  Karlstrom 
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WAGRAM  Laptop 


Name 

WAGRAM  Laptop 

System 

WAGRAM 

Owner 

DGA 

Location 

NATO  Booth 

IP 

192.168.10.20 

Tech  POC 

Jose  Ruiz 

Video  Switch  Input  # 

14 

Video  Out  Resolution 

VBS2  UK  Laptop 

Name 

VBS2  UK  Laptop 

System 

VBS2 

Owner 

DSTL 

Location 

NATO  Booth 

IP 

192.168.10.24 

Tech  POC 

Caroline  Pettitt-Morris 

Video  Switch  Input  # 

12 

Video  Out  Resolution 
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Annex  G  -  MSG-068  NETN  EXPERIMENT 
FIRST  IMPRESSION  REPORT 

(November  5,  2010) 


G.l  AIM  AND  SCOPE 

HQ-SACT,  JWC,  JFTC,  NC3A,  NATO  M&S  CoE  and  Nations,  i.e.,  Bulgaria,  France,  Germany,  Hungary, 
the  Netherlands,  Spain,  Sweden,  Turkey,  the  UK  and  the  US,  conducted  a  standalone  experiment,  NETN 
EXPERIMENT  10,  from  25  October  -  5  November  2010,  distributed,  in  Bydgoszcz,  The  Hague,  Paris,  Porton 
Down  and  Ottobrunn  in  order  to  produce  the  best  possible  environment  within  which  to  obtain  data  and 
information  required  to  validate  the  MSG-068  recommendations  for: 

•  A  secure,  persistent,  on-demand  training  capability  that  integrates  national  centers  and  NATO; 

•  Capability  and  readiness  of  NATO,  Nations  and  national  simulation  centers  to  link  into  NETN; 

•  Distributed  simulation  integrating  NATO  and  national  M&S  capabilities; 

•  Multi-granularity; 

•  Technical  standards; 

•  Distributed  training  involving  national  and  NATO  C2  and  simulation  systems;  and 

•  Shared  scenarios. 

The  experiment  achieved  the  objectives.  The  final  report  for  the  experiment  will  be  a  part  of  the  final  MSG-068 
technical  report.  This  document  is  the  first  impression  report  about  the  hypothesis  tested  during  the  experiment. 


G.2  OBSERVATIONS 

Figure  G-l  is  the  statistics  about  observations  as  of  November  5  at  09:00  (Z).  The  full  list  of  observations  is  at 
Appendix  2. 


Figure  G-1:  Observation  Statistics. 
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Draft  recommendations  based  on  the  analysis  of  observations  are  as  following: 

•  Network  performance  must  be  ensured  before  the  event  and  must  be  constantly  monitored. 

•  FAFD  must  specify: 

•  The  order  and  timing  of  joining  the  federation.  Observations  show  that  under  specific  conditions, 
the  order  of  joining  the  federation  is  important.  Other  observations  show  that  late  joiners  had 
issues  joining. 

•  The  conditions  of  using  the  FOM  (flat,  modular,  mixed).  Observations  show  that  it  is  important 
what  type  of  FOM federates  use,  since  this  influences  the  required  joining  sequence. 

•  There  must  be  a  mechanisms  to  ensure  compliance  of  federates: 

•  Federates  must  be  compliant  with  technical  standards,  FAFD  and  FOM.  Observations  show  that 
federates  fail/crash  due  to  not  handling  various  data  correctly. 

•  Data  mapping  issues  must  be  prevented.  Observations  show  that  federates  fail  to  perform  due  to 
data  not  being  correctly  mapped. 

•  Failure  of  one  federate  shouldn’t  stop  the  whole  operation.  Observations  show  that  if  a  federate 
fails,  the  whole  operation  stops  and  cannot  continue  until  the  issue  is  fixed.  In  an  exercise,  it  may 
not  be  possible  to  just  skip  an  important  phase  of  an  operation.  A  backup  solution  is  needed. 
C2  systems  need  to  be  taken  into  account  here  as  well. 

•  It  must  be  clear  how  federates  are  time  synchronized  and  time  co-ordinated.  The  federation  was 
not  time  constrained.  Observations  show  that  some  patterns  require  complex  time  co-ordination. 

•  QoS  must  be  ensured  at  application  level  (HLA)  to  prevent  non-important  communication  block 
important  communication.  Observations  show  that  federates  were  blocked  by  update  requests  while 
trying  to  perform  an  important  activity. 

•  Terrain  must  be  correlated  across  the  whole  federation.  Observation  show  that  entities  appear  at 
unexpected  locations. 

•  Further  recommendations: 

•  There  should  be  mechanisms  to  allow  dynamic  entities  and  interactions.  Observations  show  that 
there  dynamic  entities  and  interactions  were  required  but  are  currently  not  supported. 

•  Sustain  robustness  in  federation  execution  (Booster-like).  Observations  show  that  federation 
could  recover  from  short  network  failures. 

•  There  should  be  mechanisms  to  monitor  federation  execution  that  enable  instant  analysis  of  what 
is/was  going  on  in  the  federation.  Observations  show  that  it  is  difficult  to  analyse  even  simple 
failures  in  the  federation. 

•  Means  to  coordinate  simulation  operators  is  necessary.  Observations  show  that  co-ordination  was 
good  at  high  level  (federation  steering),  but  it  was  not  good  at  lower  level  (federate  interaction). 
Examples  are  airspace  management,  aircraft  location  co-ordination  during  refuelling. 

•  A  procedure  or  tool  is  needed  to  detect  and  remove/hide  unwanted/leftover  objects  from  the 
federation.  Observations  show  that  federates  do  not  remove  objects  (e.g.,  detonations)  from  the 
federation,  which  clutters  the  picture. 
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•  Ensure  that  all  simulation  developers  use  the  same,  approved,  source  code  base  for  en/decoding  of 
HLA  classes  and  interactions. 

•  Include  perception  in  the  FOM.  Aggregate  level  models  are  expected  to  provide  side-wide 
perception.  They  need  perception  information  from  entity-level  models. 

•  Issues  arising  from  multi-resolution  (location,  tracks,  damage  state,  etc.)  should  be  addressed  and 
properly  understood  by  operators.  Observations  show  that  operators  of  entity-level  models  can  be 
confused  by  behaviour  of  shadowed  entities  controlled  by  aggregate-level  models. 


G.3  THE  FIRST  IMPRESSION  OF  THE  EXPERIMENT  AUDIENCE  ABOUT  THE 
HYPOTHESIS  TESTED  IN  THE  EVENT 

Hypothesis  1:  MSG-068  NETN  Reference  FOM  and  Federation  Agreement  Recommendations  are 
Feasible  for  NETN 

MSG-068  FAD  is  proved  to  be  feasible.  However,  MSG-068  FAD  is  not  as  comprehensive  as  it  could  be. 
For  example: 

•  FAD  is  not  tested  for  large  scenarios  with  large  number  of  entities. 

•  Current  FAD  does  not  include  agreements  for  Transfer  of  Ownership. 

•  Time  management  and  DDM  services  are  not  tested. 

FOM  and  FAD  agreements  are  not  enough  for  NETN.  There  needs  to  be  more,  e.g.,  data  correlation  and  data 
reconciliation  process  were  not  entirely  sufficient. 

FEDEP  should  be  used.  For  example,  interoperability  was  achieved  between  federates  during  the  air  refuel 
injection,  but  the  representation  of  the  process  is  still  not  sufficient.  FEDEP  could  have  helped  that. 

There  are  unnecessary  complications,  especially  in  the  RPR2  FOM,  which  is  the  standalone  baseline  FOM  for 
NETN.  FAD  should  address  them.  FAD  can  specify  which  parts  are  not  used  by  any  federate. 

Hypothesis  2:  CFBLNet  is  Feasible  as  Persistent  Network  Architecture  for  NETN 
It  is  true  as  long  as  the  bearer  network  satisfies  QoS  requirements  for  NETN. 

Hypothesis  3:  NLVC  is  Compatible  with  the  NETN  Reference  Federation  Architecture 
Yes.  NFVC,  as  tested,  is  compatible  with  the  current  MSG-068  FOM  and  FAD. 

The  reverse  hypothesis  has  not  been  tested  during  the  experiment.  Some  audience  has  concerns  about  the 
reverse  hypothesis  because  RPR2  FOM  supports  only  a  subset  of  capabilities  that  some  federates  can  offer  to 
the  federation.  However,  new  FOM  modules  can  be  added  to  address  this  issue  in  the  future  as  needed. 

Hypothesis  4:  NLVC  is  a  Viable  and  Useful  Tool  to  Support  Distributed  FAC  Training  Over  a 
Wide  Area  Network 

Yes. 
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Hypothesis  5:  VBS2  NATO  is  a  Viable  and  Useful  Tool  to  Support  Distributed  C-IED  Training 

Yes. 


G.4  CONCLUSION 

The  experiment  flow  is  at  Appendix  1 .  The  detailed  observations  are  collected  by  the  analysis  team  by  using 
JEMM  application  and  enclosed  at  Appendix  2.  They  will  be  analyzed  before  the  final  report  is  released. 

Appendices 

1  -  MSG-068  Experimentation  Flow 

2  -  MSG-068  Experiment  Observations 
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EXERCISE  SCRIPT  REPORT 


^  01:  CFBLNet  Infrastructure 

01.02  Establish  CFBLNet  and  the  Internet  connections  (Storyline) 

Story 

All  nations  and  NATO  organizations  connect  to  CFBLNet. 


PS  01.02.001  Outcome  for  ping  and  ftp  tests  (Intended  Storyline  Outcome) 

Description 

-  Ensure  that  the  connections  (both  the  Internet  and  CFBLNet)  are  ready  for  the  experiment. 

-  Make  propogation  delay  and  throughput  measurements 


01 .02. API  NETN-U  open  (Action) 

Planned  Date:  270CT2010  0800Z 
Actual  Date 
Duration  1h 

Location 


Completed 

Protagonist 
Excon  Cell 
Actors 


Description 

NETN-U  is  open  and  ready  for  connections  from  experiment  participants 

^  01.02.A02  JFTC  connects  to  NETN-U  (Action) 

Planned  Date:  270CT2010  0830Z  State  Completed 

Actual  Date  Protagonist 

Duration  30m  Excon  Cell 

Location  Actors 


Description 

JFTC  connects  to  NETN-U  via  its  PoP 


01.02.101  [EXAMPLE]  JFTC  connected  to  NETN-U  (Injection) 


Planned  Date: 

270CT2010  0845Z 

State 

Draft 

Actual  Date 

Means 

CHAT 

Injector 

JFTC  RC 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

NATO, 

Description 

JFTC  reports  successful  connection  to  NETN-U 

01.02.A03  EXPCELL-ACT  prepares  a  large  file  (20  GB)  (Action) 

Planned  Date:  270CT2010  1600Z  State  Completed 

Actual  Date  Protagonist 

Duration  0m  Excon  Cell  EXPCELL-ACT 

Location  Actors 


Description 

EXPCELL-ACT  prepares  a  20  GB  file  with  any  content  in  it,  and  informs  all  the  other  EXPCELL  about 
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the  location  of  the  file.  The  other  experimentation  cells  should  be  able  to  ftp  the  file.  The  file  should  be 
availabe  both  in  CFBLNet  and  in  the  Internet. 


Q  01.02.104  Repeat  ping  tests  in  the  Internet  (Injection) 

Planned  Date:  280CT2010  1200Z  State 

Actual  Date  Means 

Injector  EXPCEN  Coordinating 

Cell 

Location  Receiver 


Cancelled 

E-MAIL 

EXPCEN 

EXPCELL-NLD,  EXPCELL-ACT, 
EXPCELL-GBR,  EXPCELL-SWE, 
EXPCELL-FRA,  EXPCELL-DEU, 


Description 

Repeat  Injection  01-02-102  for  the  Internet 


01.02.R01  Throughput,  delay  and  jitter  report  (Return) 


Planned  Date: 

Actual  Date 

280CT2010  1500Z 

State 

Draft 

Sender 

EXPCELL-NC3A 

Receiver 

EXPCEN 

Description 

EXPCELL-NC3A  collects  the  observations  and  reports  from  all  experimentation  cells  and  send  a  report 
to  EXPCEN.  The  first  draft  of  the  report  should  be  send  before  the  coordination  conference  on  October 
28. 


j  01.02.102  Start  ping  tests  (Injection) 

Planned  Date:  280CT2010  0900Z 
Actual  Date  05NOV2010  0731 Z 

Injector  EXPCEN 

Location 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

CHAT 

EXPCEN 

EXPCELL-NLD,  EXPCELL-ACT, 
EXPCELL-GBR,  EXPCELL-SWE, 
EXPCELL-FRA,  EXPCELL-DEU, 


Description 

All  experimentation  cells  ping  all  the  other  experimentation  cells  one  by  one,  and  observe  the  round  trip 
time. 


4  01.02.103  Start  ftp  tests  (Injection) 


Planned  Date:  05NOV2010  0801Z 
Actual  Date  05NOV2010  0731 Z 

Injector  EXPCEN 

Location 

Description 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-ACT, 


-  All  experimentation  cells  ftp  the  file  from  EXPCELL-ACT 

-  All  experimentation  cells  ftp  the  same  file  from  EXPCELL-SWE 

-  EXPCELL-FRA,  EXPCELL-DEU  ftp  the  same  file  from  EXPCELL-NL;  EXPCELL-ACT,  EXPCELL- 
SWE  ftp  the  same  file  from  EXPCELL-DEU;  EXPCELL-UK  and  EXPCELL-NL  ftp  the  same  file  from 
EXPCELL-ACT.  All  ftp  at  this  item  shoud  start  almost  at  the  same  time.  The  observations  should  be 
carried  out  when  all  sites  are  ftping. 


01.02.105  Repeat  ftp  tests  for  the  Internet  (Injection) 
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Planned  Date: 

280CT2010  1230Z 

State 

Injected 

Actual  Date 

05NOV2010  0731Z 

Means 

E-MAIL 

Injector 

EXPCEN 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

EXPCELL-NLD,  EXPCELL-ACT, 
EXPCELL-GBR,  EXPCELL-SWE, 
EXPCELL-FRA,  EXPCELL-DEU, 

Description 

Repeat  the  same  tests  as  in  the  Injection  01-02-103  for  the  Internet 

01.03  Manage  and  monitor  CFBLNet  infrastructure  (Storyline) 

Story 

NC3A  manages  and  monitors  the  CFBLNet  infrastructure. 

IS  01.03.001  Monitor  CFBLNet  (Intended  Storyline  Outcome) 

Description 

EXPCELL-NC3A  monitors  the  following  throughout  the  experiment: 

-  Utilization  of  bandwidth 

-  Throughput 

-  Round  trip  delay 

-  Jitter 

01.03.R01  Report  the  CFBLNet  measurements  (Return) 


Planned  Date: 

270CT2010  0000Z 

State 

Draft 

Actual  Date 

Sender 

EXPCELL-NC3A 

Receiver 

EXPCEN 

Description 

Report  about  the  CFBLNet  Measurements: 

-  Utilization 

-  Throughput 

-  Round  trip  delay 

-  Jitter 


^  02:  Operational  Scenarios 

#  02JH  Logistics  (MEDEVAC)  (Storyline) 

Story 

Two  troops  modeled  in  VR-Forces  by  EXPCELL-ESP  are  wounded.  A  medical  evacuation  plan 
is  developed  by  the  operational  people  in  EXPCELL-ACT  send  their  plan  to  MEDEVAC 
responce  cell  in  EXPCELL-DEU.  Then  EXPCELL-DEU  mplements  this  plan  in  KORA  to 
evacuate  the  wounded  troops  modelled  in  VR-Forces.  All  incident  is  also  observed  in  the  other 
models  (i.e.,  JCATS,  JTLS,  TYR,  VBS2). 

02.01.001  MSG-068  Federation  (Intended  Storyline  Outcome) 

Description 

Prove  the  operational  usefulness  of  MSG-068  federation  and  concept. 

02.01  .R01  Report  about  MEDEVAC  Experiment  (Return) 

Planned  Date:  270CT2010  0000Z  State  Draft 
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Actual  Date 

Sender  EXPCELL-DEU  Receiver  EXPCEN 


Description 

Report  about  the  feed  back  from  the  logistics  experimentation  audience. 

4  02.01.101  Operational  planning  (Injection) 


Planned  Date: 

04NOV2010  0830Z 

State 

Injected 

Actual  Date 

03NOV2010  1149Z 

Means 

DELIVERED  IN  PERSON 

Injector 

EXPCELL-DEU 

Coordinating 

Cell 

EXPCELL-DEU 

Location 

Receiver 

Logistics  Audience, 

Description 

Information  of  Experimentation  Audience  about  planned  engagement  against  terrorist  camp 

Jj  02.01.102  Capability  gap  identification  focused  on  medical  support  (Injection) 


Planned  Date: 

03NOV2010  1149Z 

State 

Injected 

Actual  Date 

03NOV2010  1150Z 

Means 

DELIVERED  IN  PERSON 

Injector 

UNKNOWN 

Coordinating 

Cell 

EXPCELL-DEU 

Location 

Receiver 

Audience, 

Description 

Information  of  Experimentation  Audience  about  the  need  for  additional  MEDEVAC  capacity 


02.01.103  Request  and  provision  of  additional  medical  support  (Injection) 


Planned  Date:  03NOV201 0  1 1 50Z 
Actual  Date  03NOV201 0  1 1 50Z 
Injector  UNKNOWN 

Location 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PHONE 

EXPCELL-DEU 

Audience, 


Description 

Based  on  the  operational  planning  of  the  combat  troops  LOCON  requests  additional  MEDEVAC  support 


02.01.104  OPORD  (Operation  Order)  Distribution  (Injection) 


Planned  Date: 

03NOV2010  1150Z 

State 

Injected 

Actual  Date 

03NOV2010  1150Z 

Means 

DELIVERED  IN  PERSON 

Injector 

UNKNOWN 

Coordinating 

Cell 

EXPCELL-DEU 

Location 

Receiver 

Audience, 

Description 

Information  of  Experimentation  Audience  about  the  medical  reinforcement  planning 


02.01  .A01  Create  TIC  in  VR-Forces  and  JCATS  ( Action ) 

Planned  Date: 

04NOV2010  0857Z 

State 

Completed 

Actual  Date 

04NOV2010  0852Z 

Protagonist 

Duration 

2h 

Excon  Cell 

EXPCELL-ESP 

Location 

Actors 

JEMM,  JEMM,  JEMM, 

Description 
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Create  a  group  of  terrorists  (the  number  is  not  important)  and  a  blue  team  in  contact  with  the  terrorists. 
Two  of  the  team  embers  are  wounded.  (58o38'12"N  15o18'58"E). 


02.01.105  Start  the  MEDEVAC  (Injection) 

Planned  Date:  04NOV201 0  0900Z 
Actual  Date  04NOV201 0  0852Z 
Injector  UNKNOWN 

Location 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

JEMM 

EXPCELL-DEU 

EXPCELL-ACT,  Logistics 
Audience,  EXPCELL-ESP, 
EXPCELL-DEU, 


Description 

HICON  deploys  medical  elements  according  to  OPPLAN 


iu£j  02.01  .A02  Call  Immediate  Report  to  MEDEVAC  Audience  in  EXPCELL-ACT  (Action) 


Planned  Date: 

04NOV2010  0902Z 

State 

Completed 

Actual  Date 

04NOV2010  0909Z 

Protagonist 

Duration 

0m 

Excon  Cell 

EXPCELL-ESF 

Location 

Actors 

JEMM,  JEMM, 

Description 

EXPCELL-ESP  sends  an  immediate  report  and  then  carry  the  wounded  personnel  to  the  safe  house 
which  will  become  Casualty  Collecting  Point  which  is  at  58o38'98"N  15o18'22"E. 

02.01  .A03  EXPCELL-ESP  sends  a  METHANE  to  the  MEDEVAC  Audience  in  EXPCELL-A  (Action) 


Planned  Date: 

04NOV2010  0907Z 

State 

Completed 

Actual  Date 

04NOV2010  091 1Z 

Protagonist 

Duration 

0m 

Excon  Cell 

EXPCELL-I 

Location 

Actors 

JEMM, 

Description 

EXPCELL-ESP  sends  a  METHANE  report  and  gives  the  details  about  the  location  (CCP)  and 
casualties. 


iu£j  02.01  .A04  MEDEVAC  Audience  request  evacuation  of  the  casualties  (Action) 

Planned  Date:  04NOV2010  0909Z  State  Completed 

Protagonist 


Actual  Date 

Duration 

Location 


04NOV2010  0923Z 
0m 


Excon  Cell 
Actors 


EXPCELL-ACT 
JEMM,  JEMM, 


Description 

MEDEVAC  Audience  in  EXPCELL-ACT  request  from  EXPCELL-DEU  the  evacuation  of  casualties  by 
helicopter 


02.01  .A05  Evacuate  the  casualties  (Action) 


Planned  Date: 

04NOV2010  091 2Z 

State 

Completed 

Actual  Date 

04NOV2010  0931Z 

Protagonist 

Duration 

0m 

Excon  Cell 

EXPCELL-DEL 

Location 

Actors 

JEMM,  JEMM, 

Description 
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A  helicopter  in  Kora  evacuates  the  wounded  personel  in  VR-Forces. 


#  Q2M  C-IED  (Storyline) 

Story 

Two  subject  matter  experts  (SME)  will  be  tasked  by  HQ-SACT  and  one  staff  officer  will  be  tasked 
by  JFTC  for  this  incident.  These  SMEs  and  the  staff  officer  will  act  as  the  trainers  for  a 
distributed  C-IED  training  using  VBS2-NATO  as  the  training  tool.  Apart  from  that  10  trainees  will 
be  assigned  by  HQ-SACT.  Trainers  will  be  in  EXPCELL-ACT  in  Bydgoszcz,  and  the  trainees  will 
stay  in  Norfolk.  All  the  data  communications  will  be  via  the  Internet. 


02.02.001  Analyze  distributed  training  effectiveness  (Intended  Storyline  Outcome) 

Description 

1 .  Trainers  will  be  surveyed  to  determine  if  they  were  able  to  conduct  effective  C-IED  training  by  using 
VBS2-NATO  although  the  trainees  are  in  a  remote  site. 

2.  The  following  will  also  be  examined: 

-  Time  and  effort  required  to  prepare  the  training. 

-  The  user  friendliness  of  the  overall  procedures  and  systems  for  the  trainees. 

-  The  time  and  effort  required  to  actually  establish  the  training  session. 


ygj  02.02.A02  Start  the  VBS2  scripts  and  scenario  to  support  the  training  (Action) 

Planned  Date:  04NOV2010  1500Z  State  Completed 

Actual  Date  Protagonist 

Duration  1d2h  Excon  Cell  EXPCELL-ACT 

Location  Actors  VBS2  (NATO), 

Description 

The  simulation  orders  and  scenario  is  not  known  yet.  The  trainers  will  develop  them  and  coordinate 
them  with  the  operators  at  least  24  hour  before  the  initial  injection  in  the  storyline. 


02.02.R01  (Return) 

Planned  Date:  05NOV201 0  1 000Z 

Actual  Date 

State 

Draft 

Sender  C-IED  Audience 

Description 

Completed  questioneries 

Receiver 

EXPCEN 

02.02.A01  Establish  connectivity  ( Action ) 

Planned  Date:  05NOV2010  1430Z 

State 

Unknown 

Actual  Date 

Protagonist 

Duration  30m 

Excon  Cell 

EXPCELL-ACT 

Location 

Actors 

VBS2  (NATO), 

Description 

Check  and  ensure  that  the  trainess  in  HQ-SACT  can  access  VBS2-NATO  server  in  JFTC,  and  they 
have  voice  communications  with  the  trainers. 


j  02.02.101  Start  lessons  planned  (Injection) 

Planned  Date:  05NOV201 0  1 500Z 
Actual  Date 

Injector  EXPCELL-ACT 


State  Draft 

Means  DELIVERED  IN  PERSON 

Coordinating  EXPCELL-ACT 
Cell 
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Location  Receiver  C-IED  Audience, 

Description 

Trainers  from  C-IED  Audience  will  be  asked  to  start  their  training  session. 


#  02.03  NLVC-1  (Storyline) 

Story 

Forward  observers  located  in  JFTC  (EXPCELL-ACT)  and  using  FACSIM  FAC  station  controls  air 
mission  (air  to  ground  attack)  that  fly  in  FACSIM  (FI  6).  FLAMES  (FI  8)  in  JFTC  (EXPCELL-ACT 
controlled)  fly  combat  air  patrol.  3  VBS2-VTK  UAVs  observe  villiage  (1  X  GBR  @  DSTL,  1  X 
NLD  @  TNO,  1  X  JWC  UAV  but  controlled  from  JFTC).  Targets  are  armed  vehicles  in  the  villiage 
and  any  escaping  vehicles.  The  objective  is  to  demonstrate  that  NLVC  concept  and  federation 
work  efficiently,  make  observations  on  the  technical  performance/procedures  for  NLVC,  and 
determine  utility  for  the  NLVC  capabiltiy  to  support  Distributed  Training  and  Exercises. 


15  02.03.001  NLVC  concept  and  federation  (Intended  Storyline  Outcome) 

Description 

The  objective  is  to  demonstrate  that  NLVC  concept  and  federation  work  efficiently,  make  observations 
on  the  technical  performance/procedures  for  NLVC,  and  determine  utility  for  the  NLVC  capabiltiy  to 
support  Distributed  Training  and  Exercises. 


02.03.101  FACs  are  given  tactical  briefing  ( Injection ) 

Planned  Date: 

04NOV2010  1000Z 

State 

Injected 

Actual  Date 

04NOV2010  0943Z 

Means 

DELIVERED  IN  PERSON 

Injector 

EXPCELL-ACT 

Coordinating 

Cell 

EXPCELL-ACT 

Location 

Receiver 

NLVC  Audience, 

Description 

The  forward  air  controllers  (FACs)  receive  a  tactical  briefing  to  set  the  situation  for  the  execution  of  the 
vignette.  The  briefing  will  direct  them  to  destroy  armed  vehicles  in  and  around  the  village. 


02.03.A01  FACs  initiate  process  to  coordinate  FI 6  support  (Action) 


Planned  Date: 

04NOV2010  1200Z 

State 

Completed 

Actual  Date 

04NOV2010  1216Z 

Protagonist 

Duration 

3h 

Excon  Cell 

EXPCELL-ACT 

Location 

Actors 

JEMM,  JEMM,  JEMM,  JEMM, 
JEMM,  JEMM,  JEMM, 

Description 

NLVC  scenario  starts.  FAC  observes  villiage  and  identifies  targets  that  will  consist  of  1  toyota  land 
cruiser  and  3  flatbed  trucks,  all  armed  with  machineguns.  FAC  will  initiate  putting  together  his  call  to  the 
aircraft  (FI 6).  When  he  is  done  he  will  contact  aircraft  and  talk  him  onto  the  target  until  the  target  is 
destroyed.  2  X  FI 8s  continue  overhead  air  patrol  while  3  UAVs  watch  village.  Executing  simulations  are 
FACSIM  (FAC  station  @  JFTC),  FLAMES,  FACSIM  (Pilot  station  @  TNO).  Observing  simulations  are 
VBS2  (@  TNO  and  UK),  VBS2  (@  JFTC),  JCATS  (@  JFTC). 


iu£j  02.03.A02  Vehicles  attempt  escape  from  village  (Action) 


Planned  Date: 
Actual  Date 
Duration 
Location 


04NOV2010  1217Z 
04NOV2010  1233Z 
3h 


State 

Protagonist 
Excon  Cell 
Actors 


Completed 

EXPCELL-ACT 

JEMM,  JEMM,  JEMM,  JEMM, 
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JEMM,  JEMM,  JEMM,  JEMM, 
JEMM,  JEMM,  JEMM, 

Description 

FAC  observes  escamping  terrorists  moving  to  the  south  east  of  the  village.  Decides  to  redirect  FI  6  onto 
these  vehicles  to  prevent  escape.  2  X  FI 8s  continue  overhead  air  patrol  while  3  UAVs  watch  village. 
Executing  simulations  are  FACSIM  (FAC  station  @  JFTC),  FLAMES,  FACSIM  (Pilot  station  @  TNO). 
Observing  simulations  are  VBS2  (@  TNO  and  UK),  VBS2  (@  JFTC),  VR-Forces  (@  FRA),  WAGRAM 
(@  FRA),  ORQUE  (@  FRA),  JCATS  (@  JFTC),  JTLS  (@  JFTC). 

02.03.R01  Observation  reports  by  NLVC  Audience  (Return) 

Planned  Date:  04NOV2010  1245Z  State  Draft 

Actual  Date 

Sender  NLVC  Audience  Receiver  EXPCEN 

Description 

Send  the  following  reports  to  EXPCEN: 

-  Technical  requirements  (bandwidth,  delay  and  jitter)  for  NLVC  federation 

-  Performance  reports  (crashes,  crash  details,  execution  speed,  time  to  start  up  the  federation) 

-  User  observtion  reports 

02.04  Shared  Scenarios  (Storyline) 

Story 

A  prototype  of  the  tool  designed  for  the  shared  scenarios  project  and  shared  scenario 
procedures  will  be  experimented.  All  the  national  experiment  cells  and  ACT  experiment  cell  will 
join  to  this  experiment. 

B  02.04.001  Comments  on  shared  scenarios  (Intended  Storyline  Outcome) 

Description 

Receive  feed  back  from  the  nations  on  shared  scenarios  concept  and  on  the  demonstrator. 

02.04.A01  Prepare  Shared  Scenario  Tool  for  the  experiment  (Action) 

Planned  Date:  03NOV2010  1600Z  State  Scheduled 

Protagonist 


Actual  Date 

Duration 

Location 


Id  Oh 


Excon  Cell 
Actors 


EXPCEN 


Description 

Prepare  the  Shared  Scenario  Tool  for  the  experiment  by  installing  it  and  loading  the  appropraite 
databases.  The  Scared  Scenario  Tool  should  be  accessible  from  the  Internet. 

Prepare  also  a  questionarie  and  send  to  all  Experiment  Cells. 

02.04.A02  Access  portal  on  internet  server  and  download  submission  form  (Action) 

Planned  Date:  04NOV2010  1527Z  State  Ongoing 

Actual  Date  04NOV2010  1526Z  Protagonist 

Duration  10m  Excon  Cell  EXPCELL-ACT 

Location  Actors 

Description 

Access  portal  on  internet  server  and  download  submission  form. 


URL:  http://82.177.169.139/SharedScenarios/Default.aspx 
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then  click  the  link  'Download  Scenario  Contribution  Tool' 


i_^  02.04.A03  Fill  in  description  of  a  scenario  t Jr 

Planned  Date:  04NOV2010  1541Z 
Actual  Date  04NOV201 0  1 526Z 
Duration  1h 

Location 

Description 

Fill  the  description  of  an  exercise  scenario  that 
You  can  start  by  adding  the  seeting  description 
using  the  setting. 


you  have  used  (Action) 

State  Ongoing 

Protagonist 

Excon  Cell  EXPCELL-ACT 

Actors 

j  have  used  in  the  past. 

d  subsequently  describe  the  scenario  that  was  built 


02.04.102  Briefing  to  participants  on  Shared  Scenario  Library  Project  (Injection) 


Planned  Date: 

04NOV2010  1400Z 

State 

Injected 

Actual  Date 

04NOV2010  1526Z 

Means 

DELIVERED  IN  PERSON 

Injector 

EXPCELL-ACT 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

Audience, 

Description 

Introductory  on  shared  scenario  project  objectives  and  role  of  experiment  in  achieving  them. 


02.04.103  Request  to  access  portal  and  download  submission  form  (Injection) 


Planned  Date: 

04NOV2010  1556Z 

State 

Injected 

Actual  Date 

04NOV2010  1526Z 

Means 

CHAT 

Injector 

EXPCELL-ACT 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

Audience, 

Description 

Request  to  download  submission  form  from  portal  on  internet 


lL^  02.04.A04  Send  submission  back  for  inclusion  (Action) 


Planned  Date:  04NOV201 0  1 627Z 
Actual  Date  04NOV201 0  1 527Z 
Duration  2m 

Location 


State 

Protagonist 
Excon  Cell 
Actors 


Ongoing 

EXPCELL-ACT 


Description 

Send  submission  back  for  inclusion. 


Either 

-  mail  to:  blackstone.steven@gmail.com 

-  use  Skype  to  transfer  file  to  msg68expcell-nc3a 

-  use  USB  Memory  stick  (JFTC  only) 


ygj  02.04.A05  Consolidate  inputs  into  library  (Action) 


Planned  Date: 

04NOV2010  1532Z 

State 

Scheduled 

Actual  Date 

Protagonist 

Duration 

30m 

Excon  Cell 

EXPCELL-ACT 

Location 

Actors 
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Description 

NC3A  shared  scenario  team  consolidate  inputs  from  participants  into  library 

l4  02.04.105  Request  to  fill  in  questionnaire  (Injection) 

Planned  Date:  05NOV2010  0700Z  State  Draft 

Actual  Date  Means  CHAT 

Injector  EXPCELL-ACT  Coordinating  EXPCEN 

Cell 

Location  Receiver  Audience, 

Description 

Request  to  fill  in  questionnaire  for  the  shared  scenario  library  part 

02.04.101  Send  shared  scenarios  questionarie  to  experiment  cells  (Injection) 


Planned  Date: 

270CT2010  0000Z 

State 

Injected 

Actual  Date 

05NOV2010  0730Z 

Means 

E-MAIL 

Injector 

EXPCEN 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

EXPCELL-NLD,  EXPCELL-ACT, 
EXPCELL-GBR,  EXPCELL-SWE, 
EXPCELL-ESP,  EXPCELL-FRA, 
EXPCELL-DEU, 

Description 

Shared  Scenarios  observer  sends  the  questionarie  to  al  the  experiment  cells,  which  will  have  access  to 
JEST  to  answer  the  questions  in  the  questionarie. 


4  02.04.104  Request  to  search  library  (Injection) 

Planned  Date:  05NOV201 0  0800Z 
Actual  Date 

Injector  EXPCELL-ACT 

Location 


State  Draft 

Means  CHAT 

Coordinating  EXPCEN 
Cell 

Receiver  Audience, 


Description 

Request  participants  to  search  the  library,  find  their  own  submitted  scenario.  Look  for  other  scenarios. 


02.04.A06  Search  scenario  library  (Action) 

Planned  Date:  05NOV2010  0801Z  State  Unknown 

Actual  Date  Protagonist 

Duration  45m  Excon  Cell 

Location  Actors 


Description 

Search  scenario  library 

either  through  your  RTA  account:  http://nsrl.rta.nato.int/nsrl/login.do 
or  through: 

http://82. 1 77. 1 69. 1 39/SharedScenarios 

02.04.R01  Report  about  shared  scenarios  (Return) 

Planned  Date:  05NOV2010  1000Z  State  Draft 

Actual  Date 
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Sender  EXPCELL-ACT  Receiver  EXPCEN 

Description 

Send  a  reportabout  the  feed  back  from  the  experimentation  cells. 

#  02.05  NLVC-2  (Storyline) 

Story 

Forward  observers  located  in  JFTC  (EXPCELL-ACT)  and  using  FACSIM  FAC  station  controls  air 
mission  (air  to  ground  attack)  that  fly  in  FACSIM  (FI  6).  FLAMES  (FI  8)  in  JFTC  (EXPCELL-ACT 
controlled)  fly  combat  air  patrol.  3  VBS2-VTK  UAVs  observe  villiage  (1  X  GBR  @  DSTL,  1  X 
NLD  @  TNO,  1  X  JWC  UAV  but  controlled  from  JFTC).  Targets  are  armed  vehicles  in  the  villiage 
and  any  escaping  vehicles.  The  objective  is  to  demonstrate  that  NLVC  concept  and  federation 
work  efficiently,  make  observations  on  the  technical  performance/procedures  for  NLVC,  and 
determine  utility  for  the  NLVC  capabiltiy  to  support  Distributed  Training  and  Exercises. 

02.05.001  NLVC  concept  and  federation  (Intended  Storyline  Outcome) 

Description 

The  objective  is  to  demonstrate  that  NLVC  concept  and  federation  work  efficiently,  make  observations 
on  the  technical  performance/procedures  for  NLVC,  and  determine  utility  for  the  NLVC  capabiltiy  to 
support  Distributed  Training  and  Exercises. 


02.05.101  FACs  are  given  tactical  briefing  ( Injection ) 

Planned  Date: 

04NOV2010  1000Z 

State 

Injected 

Actual  Date 

04NOV2010  0943Z 

Means 

DELIVERED  IN  PERSON 

Injector 

EXPCELL-ACT 

Coordinating 

Cell 

EXPCELL-ACT 

Location 

Receiver 

NLVC  Audience, 

Description 

The  forward  air  controllers  (FACs)  receive  a  tactical  briefing  to  set  the  situation  for  the  execution  of  the 
vignette.  The  briefing  will  direct  them  to  destroy  armed  vehicles  in  and  around  the  village. 

1  02.05.R01  Observation  reports  by  NLVC  Audience  (Return) 


Planned  Date: 

04NOV2010  1245Z 

State 

Draft 

Actual  Date 

Sender 

NLVC  Audience 

Receiver 

EXPCEN 

Description 

Send  the  following  reports  to  EXPCEN: 

-  Technical  requirements  (bandwidth,  delay  and  jitter)  for  NLVC  federation 

-  Performance  reports  (crashes,  crash  details,  execution  speed,  time  to  start  up  the  federation) 

-  User  observtion  reports 

ygj  02.05.A01  FACs  initiate  process  to  coordinate  FI 6  support  (Action) 


Planned  Date: 

04NOV2010  1300Z 

State 

Completed 

Actual  Date 

Protagonist 

Duration 

3h 

Excon  Cell 

EXPCELL-ACT 

Location 

Actors 

JEMM,  JEMM,  JEMM,  JEMM, 
JEMM,  JEMM,  JEMM, 

Description 

NLVC  scenario  starts.  FAC  observes  villiage  and  identifies  targets  that  will  consist  of  1  toyota  land 
cruiser  and  3  flatbed  trucks,  all  armed  with  machineguns.  FAC  will  initiate  putting  together  his  call  to  the 
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aircraft  (FI 6).  When  he  is  done  he  will  contact  aircraft  and  talk  him  onto  the  target  until  the  target  is 
destroyed.  2  X  FI 8s  continue  overhead  air  patrol  while  3  UAVs  watch  village.  Executing  simulations  are 
FACSIM  (FAC  station  @  JFTC),  FLAMES,  FACSIM  (Pilot  station  @  TNO).  Observing  simulations  are 
VBS2  (@  TNO  and  UK),  VBS2  (@  JFTC),  JCATS  (@  JFTC). 


02.05.A02  Vehicles  attempt  escape  from  village  (Action) 


Planned  Date: 

04NOV2010  1301Z 

State 

Actual  Date 

Protagonist 

Duration 

3h 

Excon  Cell 

Location 

Actors 

Completed 


EXPCELL-ACT 

JEMM,  JEMM,  JEMM,  JEMM, 
JEMM,  JEMM,  JEMM,  JEMM, 
JEMM,  JEMM,  JEMM, 


Description 

FAC  observes  escamping  terrorists  moving  to  the  south  east  of  the  village.  Decides  to  redirect  FI  6  onto 
these  vehicles  to  prevent  escape.  2  X  FI 8s  continue  overhead  air  patrol  while  3  UAVs  watch  village. 
Executing  simulations  are  FACSIM  (FAC  station  @  JFTC),  FLAMES,  FACSIM  (Pilot  station  @  TNO). 
Observing  simulations  are  VBS2  (@  TNO  and  UK),  VBS2  (@  JFTC),  VR-Forces  (@  FRA),  WAGRAM 
(@  FRA),  ORQUE  (@  FRA),  JCATS  (@  JFTC),  JTLS  (@  JFTC). 


#  02.06  NLVC-3  (Storyline) 

Story 

Forward  observers  located  in  JFTC  (EXPCELL-ACT)  and  using  FACSIM  FAC  station  controls  air 
mission  (air  to  ground  attack)  that  fly  in  FACSIM  (FI  6).  FLAMES  (FI  8)  in  JFTC  (EXPCELL-ACT 
controlled)  fly  combat  air  patrol.  3  VBS2-VTK  UAVs  observe  villiage  (1  X  GBR  @  DSTL,  1  X 
NLD  @  TNO,  1  X  JWC  UAV  but  controlled  from  JFTC).  Targets  are  armed  vehicles  in  the  villiage 
and  any  escaping  vehicles.  The  objective  is  to  demonstrate  that  NLVC  concept  and  federation 
work  efficiently,  make  observations  on  the  technical  performance/procedures  for  NLVC,  and 
determine  utility  for  the  NLVC  capabiltiy  to  support  Distributed  Training  and  Exercises. 

L^j  02.06.001  NLVC  concept  and  federation  (Intended  Storyline  Outcome) 

Description 

The  objective  is  to  demonstrate  that  NLVC  concept  and  federation  work  efficiently,  make  observations 
on  the  technical  performance/procedures  for  NLVC,  and  determine  utility  for  the  NLVC  capabiltiy  to 
support  Distributed  Training  and  Exercises. 


02.06.101  FACs  are  given  tactical  briefing  ( Injection ) 

Planned  Date: 

04NOV2010  1000Z 

State 

Injected 

Actual  Date 

04NOV2010  0943Z 

Means 

DELIVERED  IN  PERSON 

Injector 

EXPCELL-ACT 

Coordinating 

Cell 

EXPCELL-ACT 

Location 

Receiver 

NLVC  Audience, 

Description 

The  forward  air  controllers  (FACs)  receive  a  tactical  briefing  to  set  the  situation  for  the  execution  of  the 
vignette.  The  briefing  will  direct  them  to  destroy  armed  vehicles  in  and  around  the  village. 


02.06.R01  Observation  reports  bv  NLVC  Audience  ( Return ) 

Planned  Date: 

04NOV2010  1245Z 

State 

Draft 

Actual  Date 

Sender 

NLVC  Audience 

Receiver 

EXPCEN 

Description 
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Send  the  following  reports  to  EXPCEN: 

-  Technical  requirements  (bandwidth,  delay  and  jitter)  for  NLVC  federation 

-  Performance  reports  (crashes,  crash  details,  execution  speed,  time  to  start  up  the  federation) 

-  User  observtion  reports 


02.06.A01  FACs  initiate  process  to  coordinate  FI 6  support  (Action) 


Planned  Date: 

04NOV2010  1400Z 

State 

Completed 

Actual  Date 

Protagonist 

Duration 

3h 

Excon  Cell 

EXPCELL-ACT 

Location 

Actors 

JEMM,  JEMM,  JEMM,  JEMM, 
JEMM,  JEMM,  JEMM,  JEMM, 
JEMM,  JEMM,  JEMM, 

Description 

NLVC  scenario  starts.  FAC  observes  villiage  and  identifies  targets  that  will  consist  of  1  toyota  land 
cruiser  and  3  flatbed  trucks,  all  armed  with  machineguns.  FAC  will  initiate  putting  together  his  call  to  the 
aircraft  (FI 6).  When  he  is  done  he  will  contact  aircraft  and  talk  him  onto  the  target  until  the  target  is 
destroyed.  2  X  FI 8s  continue  overhead  air  patrol  while  3  UAVs  watch  village.  Executing  simulations  are 
FACSIM  (FAC  station  @  JFTC),  FLAMES,  FACSIM  (Pilot  station  @  TNO).  Observing  simulations  are 
VBS2  (@  TNO  and  UK),  VBS2  (@  JFTC),  VR-Forces  (@  FRA),  WAGRAM  (@  FRA),  ORQUE  (@ 

FRA),  JCATS  (@  JFTC),  JTLS  (@  JFTC). 


02.06.A02  Vehicles  attempt  escape  from  village  (Action) 


Planned  Date:  04NOV2010  1401Z 
Actual  Date  04NOV2010  1429Z 
Duration  3h 

Location 


State 

Protagonist 
Excon  Cell 
Actors 


Completed 


EXPCELL-ACT 

JEMM,  JEMM,  JEMM,  JEMM, 
JEMM,  JEMM,  JEMM,  JEMM, 
JEMM,  JEMM,  JEMM, 


Description 

FAC  observes  escamping  terrorists  moving  to  the  south  east  of  the  village.  Decides  to  redirect  FI  6  onto 
these  vehicles  to  prevent  escape.  2  X  FI 8s  continue  overhead  air  patrol  while  3  UAVs  watch  village. 
Executing  simulations  are  FACSIM  (FAC  station  @  JFTC),  FLAMES,  FACSIM  (Pilot  station  @  TNO). 
Observing  simulations  are  VBS2  (@  TNO  and  UK),  VBS2  (@  JFTC),  VR-Forces  (@  FRA),  WAGRAM 
(@  FRA),  ORQUE  (@  FRA),  JCATS  (@  JFTC),  JTLS  (@  JFTC). 


03:  Technical  Scenarios 

#  03.01  Assault  Campaign  1  (Internet  with  booster)  (Storyline) 

Story 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

(5  03.01.001  Campaign  1  (Intended  Storyline  Outcome) 

Description 

Prove  that 

-  MSG-068  NETN  concept  is  feasible 

-  MSG-068  NETN  Reference  Federation  Architecture  is  practical 
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03.01  .A01  Sea 

lift  (Action) 

Planned  Date: 

02NOV2010  0856Z 

State 

Completed 

Actual  Date 

02NOV2010  0856Z 

Protagonist 

Duration 

0m 

Excon  Cell 

EXPCELL-FRA 

Location 

Actors 

JEMM,  JEMM,  JEMM, 

Description 

Orque  will  provide  transportation  service. 

WAGRAM  will  consume  the  service  provided  by  Orque. 

VR-Forces  will  also  consume. 

Port  for  embarkation  is  VISBY. 

Port  for  debarkation  is  OXELOSUND. 

The  units  to  be  transfered  wil  be  selected  by  the  related  experimentation  cell. 

Once  embarkation  is  complete,  simulation  time  will  be  increased  during  transfer. 

During  transport  the  unit  modeled  in  WAGRAM  will  be  inactive.  All  subscribing  systems  shall  handle  the 
inactive  state  and  set  the  new  location  once  the  service  has  been  completed  and  the  unit  has  debarked. 

-4  03.01.101  Sea  lift  (Injection) 

Planned  Date:  02NOV201 0  0858Z 
Actual  Date  02NOV201 0  0856Z 
Injector  EXPCEN 

Location 

Description 

Sea  lift  of  forces 

■  03.01.102  UAV  Recce  (Injection) 

Planned  Date:  02NOV2010  091 1Z 
Actual  Date  02NOV201 0  0909Z 

Injector  EXPCEN 

Location 

Description 

UAV  is  tasked  to  monitor  the  area 

ygj  03.01  .A02  UAV  Recce  (Action) 

Planned  Date:  02NOV201 0  0909Z 
Actual  Date  02NOV201 0  091 0Z 
Duration  0m 

Location 

Description 

The  UAV  Reconnaissance  vignette  demonstrates  the  use  of  RPR-FOM  based,  platform  level,  virtual 
simulation  VBS2  and  constructive  simulation  JCATS.  Radio  simulation  is  used  to  model  communication 
between  UAV  operator  and  ground  commander.  JCATS  stimulates  VBS2  with  entities  representing  the 
terrorist  camp  buildings,  vehicles  and  individual  humans.  VBS2  simulates  UAV  and  generates  a  UAV 
feed  over  the  area  including  visualization  of  JCATS  generated  entities. 

Fly  a  predator  in  VBS2.  Initial  location  for  the  predator  is  57.388402,  18.189365,  2000. 

Move  entities  in  JCATS  around  buildingl  (58.643177,  15.316343,  0)  and  building  2  (58.639517, 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-ACT,  EXPCELL-ESP, 
EXPCELL-FRA, 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-ACT,  EXPCELL-GBR, 


State 

Protagonist 
Excon  Cell 
Actors 


Completed 

EXPCELL-GBR 
JEMM,  JEMM, 
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15.311118,  0) 


03.01  .A03  Cruise  missile  (Action) 

Planned  Date:  02NOV201 0  0923Z 
Actual  Date  02NOV201 0  0923Z 
Duration  0m 

Location 


State  Completed 

Protagonist 

Excon  Cell  EXPCELL-FRA 

Actors  JEMM,  JEMM,  JEMM,  JEMM, 


Description 

This  vignette  demonstrates  the  representation  of  RPR-FOM  based  munition  objects  with  Weapon  Fire 
and  Munition  Detonation  interactions.  Based  on  target  information  collected  during  UAV  Recce  and 
Identification,  a  french  SCALP  Naval  cruise  missile  is  launcehd  from  a  french  FREMM  frigate  off  the 
coast  of  Bogaland.  The  target  has  been  identified  as  a  terrorist  weapon  depot  in  the  northen  group  of 
buildings  of  the  terrorist  camp.  Location  and  target  parameters  are  reported  and  a  fire  mission 
communicatted  using  radio  (PLEXcomm)  to  the  ShipCmd.  The  french  simulation  Orque  models  the 
frigate  and  the  cruise  missile  launch,  flight  and  detonation.  Effects  are  observed  by  UAV  modeled  using 
VBS2. 

UAV  is  a  predator  and  initial  location  (when  the  injection  is  given)  is  57.388402,  18.189365,  2000. 

The  location  of  FREMM  is  57.51 1 ,  18.055,0. 

The  target  of  SCALP  is  a  building  at  location  58.6431 77,  1 5.31 6343,  0. 

The  building  is  an  entity  in  JCATS. 


^  03.01.103  Cruise  missile  (Injection) 

Planned  Date:  02NOV201 0  0924Z 
Actual  Date  02NOV201 0  0923Z 

Injector  EXPCEN 

Location 

Description 

Cruise  strike  ordered  and  executed 


State  Injected 

Means  PLEXComm  Radio 

Coordinating  EXPCEN 
Cell 

Receiver  EXPCELL-NLD,  EXPCELL-ACT, 

EXPCELL-GBR,  EXPCELL-FRA, 


i  03.01.104  Ground  Strike  with  CAS/CCA  (Injection) 


Planned  Date:  02NOV201 0  0938Z 
Actual  Date  02NOV201 0  0936Z 

Injector  EXPCEN 

Location 


State 

Means 

Coordinating 

Cell 

Receiver 


Description 

Ground  strike  with  CAS/CCA 

FI  03.01  .A05  Marine  blocking  (Action) 

Planned  Date:  02NOV2010  0951Z 
Actual  Date 
Duration  0m 

Location 


State 

Protagonist 
Excon  Cell 
Actors 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-NLD,  EXPCELL-ACT, 
EXPCELL-GBR,  EXPCELL-ESP, 
EXPCELL-FRA, 


Cancelled 


EXPCELL-ACT 
JEMM,  JEMM, 


Description 

USMC  in  JCATS  positioned  south  of  Terrorist  Camp  in  Blocking  position.  Terrorists  (both  in  JCATS  and 
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VBS2-GBR)  moving  south  from  the  camp  will  be  engaged  by  USMC. 

n  03.01  .A06  MEDEVAC  (Action) 

Planned  Date:  02NOV2010  0951Z  State  Cancelled 

Actual  Date  Protagonist 

Duration  0m  Excon  Cell  EXPCELL-DEU 

Location  Actors  JEMM,  JEMM, 

Description 

Evacuate  wounded  Spanish  infantry  in  VR-Forces  using  German  medevac  units. in  Kora.  The 
woundesoldier  will  be  in  the  vicinity  of  the  ground  strike.  Exact  location  will  be  determined  based  on  the 
ground  strike.  The  wounded  soldier  can  be  evacuated  to  any  field  hospital  selected  by  EXPCELL-DEU. 

Q  03.01.105  Marine  Blocking  Position  (Injection) 

Planned  Date:  02NOV2010  0951Z 
Actual  Date 

Injector  EXPCEN 

Location 

Description 

Marine  blocking  position 

E  03.01.106  MEDEVAC  (Injection) 

Planned  Date:  02NOV2010  0951Z 
Actual  Date 

Injector  EXPCEN 

Location 

Description 

MEDEVAC 

03.01  .A04  Ground  strike  (Action) 

Planned  Date:  02NOV201 0  0936Z 
Actual  Date  02NOV201 0  1 006Z 
Duration  0m 

Location 

Description 

Multinational  combined  ground-strike  from  north  of  terrorist  camp.  Swedish  MBT  platoon  approach  from 
north  supported  by  indirect  fire  from  French  221st  Motorized  Infantry  Battalion  and  mechanized  infrantry 
from  US  and  Spain  (Mech  Coy:  BIMZ  1/31  Covadonga  3aCia). 

•FRA  (Indirect  Fire  Support,  221  BATIN F  48xVBCI  +  16xVAB  +  8xMo120mm  +  16xMilan  )  at  WAGRAM. 
•USA  (APC  Stryker)at  JCATS. 

•ESP  (AFV  ASCOD  PIZARRO,  BIMZ  1/31  Covadonga  3th  Coy:  13xPizarro,  4xTruks,  84xsoldiers)  at 
VR-Forces. 

-  JPECT  will  conduct  an  air  strike. 

-  VR-Forces  will  also  conduct  a  close  air  support 

|  03.01.R01  Report  about  the  results  of  Campaign  1  with  Booster  (Return) 


State 

Means 

Coordinating 

Cell 

Receiver 


Cancelled 
PLEXComm  Radio 
EXPCEN 

EXPCELL-ACT,  EXPCELL-GBR, 


State 

Means 

Coordinating 

Cell 

Receiver 


Cancelled 
PLEXComm  Radio 
EXPCEN 

EXPCELL-ESP,  EXPCELL-DEU, 


State 

Protagonist 
Excon  Cell 
Actors 


Completed 

EXPCELL-ACT 

JEMM,  JEMM,  JEMM,  JEMM, 
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Planned  Date: 

Actual  Date 

02NOV2010  1100Z 

State 

Draft 

Sender 

EXPCELL-ACT 

Receiver 

EXPCEN 

Description 

Report  about  the  results  of  Campaign  1  with  Booster. 

03.02  Assault  Campaign  2  (CFBLNet  with  booster)  (Storyline) 

Story 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 

Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

15  03.02.001  MSG-068  NETN  Concept  and  Reference  Federation  (Intended  Storyline  Outcome) 

Description 

Prove  that 

-  MSG-068  NETN  concept  is  feasible 

-  MSG-068  NETN  Reference  Federation  Architecture  is  practical 

|  03.02.R01  Report  about  the  results  of  Campaign  2  with  Booster  (Return) 


Planned  Date: 

Actual  Date 

03NOV2010  1100Z 

State 

Draft 

Sender 

Description 

EXPCELL-ACT 

Receiver 

EXPCEN 

Report  about  the  results  of  Campaign  2  with  Booster. 

03.02.A01  UAV  Recce  t Action ) 

Planned  Date: 

03NOV2010  1239Z 

State 

Completed 

Actual  Date 

03NOV2010  1239Z 

Protagonist 

Duration 

2h 

Excon  Cell 

EXPCELL-AC" 

Location 

Description 

Actors 

JEMM,  JEMM, 

The  UAV  Reconnaissance  vignette  demonstrates  the  use  of  RPR-FOM  based,  platform  level,  virtual 
simulation  VBS2  and  constructive  simulation  JCATS.  Radio  simulation  is  used  to  model  communication 
between  UAV  operator  and  ground  commander.  JCATS  stimulates  VBS2  with  entities  representing  the 
terrorist  camp  buildings,  vehicles  and  individual  humans.  VBS2  simulates  UAV  and  generates  a  UAV 
feed  over  the  area  including  visualization  of  JCATS  generated  entities. 

Fly  a  predator  in  VBS2(NLD).  Initial  location  for  the  predator  is  57.388402,  18.189365,  2000. 

Move  entities  in  JCATS  around  buildingl  (58.643177,  15.316343,  0)  and  building  2  (58.639517, 
15.311118,0) 

J*j  03.02.101  UAV  Recce  (Injection) 

Planned  Date:  03NOV2010  1300Z  State  Injected 

Actual  Date  03NOV2010  1239Z  Means  PLEXComm  Radio 

Injector  EXPCEN  Coordinating  EXPCEN 

Cell 
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Location  Receiver  EXPCELL-NLD,  EXPCELL-ACT, 

Description 

UAV  is  tasked  to  monitor  the  area.  JCATS  entities  are  reflected  in  VBS2. 

iu£j  03.02.A02  Implement  air  strikes  by  using  VBS2-NLD,  VBS2-UK  and  JPECT  (Action) 


Planned  Date: 

03NOV2010  1314Z 

State 

Completed 

Actual  Date 

Protagonist 

Duration 

15m 

Excon  Cell 

EXPCELL-ACT 

Location 

Actors 

JEMM,  JEMM,  JEMM,  JEMM, 

Description 

Air  missions  flying  in  FLAMES  strike  the  terrorist  camp  in  JCATS.  Select  any  type  of  aircraft  and 
ammunition. 

UAVs  in  VBS2  UK  and  VBS2  NLD  observe. 

JCATS  shoots  the  air  missions  in  FLAMES. 

03.02.102  Air  Strike  (Injection) 

Planned  Date:  03NOV201 0  1 254Z 

Actual  Date  03NOV2010  1314Z 

Injector  EXPCEN 

Location 

Description 

Air  strike  ordered  and  executed 

i  03.02.103  Air  refuel  (Injection) 

Planned  Date:  03NOV201 0  1 329Z 

Actual  Date  03NOV2010  1314Z 

Injector  EXPCEN 

Location 

Description 

Start  air  refuel  incident 

03.02.A03  Air  refuel  (Action) 

Planned  Date:  03NOV2010  1314Z 

Actual  Date  03NOV201 0  1 322Z 

Duration  15m 

Location 

Description 

A  request  for  air  refule  is  comming  from  an  aircraft  modelled  by  JTLS  in  the  south  of  Bogaland.  A  tanker 
aircraft  in  Orque  offers  supply  service  to  this  aircraft  and  the  services  are  supplied,  and  both  aircraft 
goes  on  their  way.TYR  is  passive. 

1L^  03.02.A04  Ground  strike  (aggregate)  (Action) 

Planned  Date:  03NOV2010  1356Z  State  Completed 

Actual  Date  03NOV2010  1356Z  Protagonist 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-NLD,  EXPCELL-ACT, 
EXPCELL-GBR,  UNKNOWN, 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-ACT,  EXPCELL-SWE, 
EXPCELL-FRA, 


State 

Protagonist 
Excon  Cell 
Actors 


Completed 

EXPCELL-SWE 
JEMM,  JEMM,  JEMM, 
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Duration  15m  Excon  Cell  EXPCELL-FRA 

Location  Actors  JEMM,  JEMM,  JEMM,  JEMM, 

Description 

Terrorists  are  in  JCATS  and  in  the  camp  area. 

Aggregate  units  in  TYR,  WAGRAM  and  JTLS  (select  appropriate  one  from  your  ORBAT)  engage 
terrorist  camp. 


03.02.104  Ground  strike  2  (Aggregated)  (Injection) 


Planned  Date:  03NOV201 0  1 329Z 
Actual  Date  03NOV201 0  1 356Z 
Injector  EXPCEN 

Location 

Description 

Indirect  fire  (platform-level) 

i  03.02.105  Marine  Blocking  (Injection) 

Planned  Date:  03NOV2010  1411Z 
Actual  Date  03NOV2010  1412Z 
Injector  EXPCEN 

Location 

Description 

Marine  blocking 

1^2}  03.02.A05  Marine  blocking  (Action) 

Planned  Date:  03NOV2010  1412Z 
Actual  Date  03NOV2010  1428Z 
Duration  0m 

Location 


State  Injected 

Means  PLEXComm  Radio 

Coordinating  EXPCEN 

Cell 

Receiver  EXPCELL-ACT,  EXPCELL-SWE, 

EXPCELL-FRA, 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-NLD,  EXPCELL-ACT, 


State  Completed 

Protagonist 

Excon  Cell  EXPCELL-ACT 

Actors  JEMM,  JEMM, 


Description 

USMC  in  JCATS  positioned  south  of  Terrorist  Camp  in  Blocking  position.  Terrorists  (both  in  JCATS  and 
VBS2-NLD)  moving  south  from  the  camp  will  be  engaged  by  USMC. 


03.02.106  Hostage  Situation  ( Injection ) 

Planned  Date: 

03NOV2010  1427Z 

State 

Injected 

Actual  Date 

03NOV2010  1429Z 

Means 

PLEXComm  Radio 

Injector 

EXPCEN 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

EXPCELL-SWE, 

Description 

Hostage  taken  and  situation  resolved 

03.02.A06  Hostage  situation  ( Action ) 

Planned  Date: 

03NOV2010  1429Z 

State 

Completed 

Actual  Date 

03NOV2010  1434Z 

Protagonist 
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Duration  Om  Excon  Cell  EXPCELL-SWE 

Location  Actors  JEMM,  JEMM, 

Description 

TYR  will  request  the  transport  a  group  of  hostages  held  outside  the  terrorist  camp  and  PitchActors  will 
provide  the  transport. 

jjj  03.02.108  Ammunition  resupply  (Injection) 

Planned  Date:  03NOV2010  1444Z 
Actual  Date  03NOV2010  1443Z 

Injector  EXPCEN 

Location 

Description 

Ammunition  resuply 

R  03.02.A07  Repair  (Action) 

Planned  Date:  03NOV2010  1444Z 
Actual  Date 
Duration  15m 

Location 

Description 

JCATS  request  the  repair  of  a  broken  down  vehicle.  A  vehicle  that  needs  maintenance  after  the  ground 
strike....  WAGRAM  provides  an  engineering  unit  supplying  the  service. 

ygj  03.02.A08  Ammunition  resuply  (Action) 


Planned  Date: 

03NOV2010  1443Z 

State 

Completed 

Actual  Date 

03NOV2010  1444Z 

Protagonist 

Duration 

15m 

Excon  Cell 

EXPCELL-FR/ 

Location 

Actors 

JEMM,  JEMM, 

Description 

JCATS  requests  an  ammunition  resupply  and  WAGRAM  provides  that. 

K  03.02.107  Repair  (Injection) 

Planned  Date:  03NOV2010  1444Z 
Actual  Date 

Injector  EXPCEN 

Location 

Description 

Repair  logistics  pattern 

#  03.03  Assault  Campaign  1  (CFBLNet  with  booster)  (Storyline) 

Story 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 


State 

Means 

Coordinating 

Cell 

Receiver 


Cancelled 
PLEXComm  Radio 
EXPCEN 

EXPCELL-ACT,  EXPCELL-FRA, 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-ACT,  EXPCELL-FRA, 


State 

Protagonist 
Excon  Cell 
Actors 


Cancelled 

EXPCELL-ACT 
JEMM,  JEMM, 
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The  decision  to  attack  has  been  taken. 

L 03.03.001  Campaign  1  (Intended  Storyline  Outcome) 

Description 

Prove  that 

-  MSG-068  NETN  concept  is  feasible 

-  MSG-068  NETN  Reference  Federation  Architecture  is  practical 

03.03.R01  Report  about  the  results  of  Campaign  1  with  Booster  (Return) 


Planned  Date: 

Actual  Date 

02NOV2010  1100Z 

State 

Draft 

Sender 

Description 

EXPCELL-ACT 

Receiver 

EXPCEN 

Report  about  the  results  of  Campaign  1  with  Booster. 

03.03.A01  Sea  lift  ( Action ) 

Planned  Date: 

03NOV2010  0745Z 

State 

Completed 

Actual  Date 

03NOV2010  0745Z 

Protagonist 

Duration 

0m 

Excon  Cell 

EXPCELL-FRA 

Location 

Description 

Actors 

JEMM,  JEMM,  JEMM, 

Orque  will  provide  transportation  service. 

WAGRAM  will  consume  the  service  provided  by  Orque. 

VR-Forces  will  also  consume. 

Port  for  embarkation  is  VISBY. 

Port  for  debarkation  is  OXELOSUND. 

The  units  to  be  transfered  wil  be  selected  by  the  related  experimentation  cell. 

Once  embarkation  is  complete,  simulation  time  will  be  increased  during  transfer. 

During  transport  the  unit  modeled  in  WAGRAM  will  be  inactive.  All  subscribing  systems  shall  handle  the 
inactive  state  and  set  the  new  location  once  the  service  has  been  completed  and  the  unit  has  debarked. 

i_4{  03.03.101  Sea  lift  (Injection) 

Planned  Date:  03NOV201 0  0745Z 
Actual  Date  03NOV201 0  0745Z 
Injector  EXPCEN 

Location 

Description 

Sea  lift  of  forces 

^  03.03.A02  UAV  Recce  (Action) 

Planned  Date:  03NOV201 0  0804Z 
Actual  Date  03NOV201 0  0804Z 
Duration  0m 

Location 

Description 

The  UAV  Reconnaissance  vignette  demonstrates  the  use  of  RPR-FOM  based,  platform  level,  virtual 
simulation  VBS2  and  constructive  simulation  JCATS.  Radio  simulation  is  used  to  model  communication 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-ACT,  EXPCELL-ESP, 
EXPCELL-FRA, 


State 

Protagonist 
Excon  Cell 
Actors 


Completed 

EXPCELL-GBR 
JEMM,  JEMM, 
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between  UAV  operator  and  ground  commander.  JCATS  stimulates  VBS2  with  entities  representing  the 
terrorist  camp  buildings,  vehicles  and  individual  humans.  VBS2  simulates  UAV  and  generates  a  UAV 
feed  over  the  area  including  visualization  of  JCATS  generated  entities. 

Fly  a  predator  in  VBS2.  Initial  location  for  the  predator  is  57.388402,  18.189365,  2000. 

Move  entities  in  JCATS  around  buildingl  (58.643177,  15.316343,  0)  and  building  2  (58.639517, 
15.311118,0) 

Jj  03.03.102  UAV  Recce  (Injection) 

Planned  Date:  03NOV201 0  0800Z 
Actual  Date  03NOV201 0  0804Z 
Injector  EXPCEN 

Location 

Description 

UAV  is  tasked  to  monitor  the  area 

03.03.103  Cruise  missile  (Injection) 

Planned  Date:  03NOV201 0  081 9Z 
Actual  Date  03NOV201 0  0903Z 
Injector  EXPCEN 

Location 

Description 

Cruise  strike  ordered  and  executed 

ugf  03.03.A03  Cruise  missile  (Action) 

Planned  Date:  03NOV201 0  0903Z 
Actual  Date  03NOV201 0  091 5Z 
Duration  0m 

Location 

Description 

This  vignette  demonstrates  the  representation  of  RPR-FOM  based  munition  objects  with  Weapon  Fire 
and  Munition  Detonation  interactions.  Based  on  target  information  collected  during  UAV  Recce  and 
Identification,  a  french  SCALP  Naval  cruise  missile  is  launcehd  from  a  french  FREMM  frigate  off  the 
coast  of  Bogaland.  The  target  has  been  identified  as  a  terrorist  weapon  depot  in  the  northen  group  of 
buildings  of  the  terrorist  camp.  Location  and  target  parameters  are  reported  and  a  fire  mission 
communicatted  using  radio  (PLEXcomm)  to  the  ShipCmd.  The  french  simulation  Orque  models  the 
frigate  and  the  cruise  missile  launch,  flight  and  detonation.  Effects  are  observed  by  UAV  modeled  using 
VBS2. 

UAV  is  a  predator  and  initial  location  (when  the  injection  is  given)  is  57.388402,  18.189365,  2000. 

The  location  of  FREMM  is  57.51 1 ,  18.055,0. 

The  target  of  SCALP  is  a  building  at  location  58.6431 77,  1 5.31 6343,  0. 

The  building  is  an  entity  in  JCATS. 

03.03.A04  Ground  strike  (Action) 

Planned  Date:  03NOV2010  0952Z  State  Completed 

Actual  Date  03NOV2010  0952Z  Protagonist 

Duration  0m  Excon  Cell  EXPCELL-ACT 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-ACT,  EXPCELL-GBR, 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-NLD,  EXPCELL-ACT, 
EXPCELL-GBR,  EXPCELL-FRA, 


State 

Protagonist 
Excon  Cell 
Actors 


Completed 

EXPCELL-FRA 

JEMM,  JEMM,  JEMM,  JEMM, 
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Location  Actors  JEMM,  JEMM,  JEMM,  JEMM, 

JEMM, 

Description 

Multinational  combined  ground-strike  from  north  of  terrorist  camp.  Swedish  MBT  platoon  approach  from 
north  supported  by  indirect  fire  from  French  221st  Motorized  Infantry  Battalion  and  mechanized  infrantry 
from  US  and  Spain  (Mech  Coy:  BIMZ  1/31  Covadonga  3aCia). 

•FRA  (Indirect  Fire  Support,  221  BATIN F  48xVBCI  +  16xVAB  +  8xMo120mm  +  16xMilan  )  at  WAGRAM. 
•USA  (APC  Stryker)at  JCATS. 

•ESP  (AFV  ASCOD  PIZARRO,  BIMZ  1/31  Covadonga  3th  Coy:  13xPizarro,  4xTruks,  84xsoldiers)  at 
VR-Forces. 

-  FLAMES  flies  air  to  ground  attack  (CAS)  and  observe  that  with  FACSIM 

jj*j  03.03.104  Ground  Strike  with  CAS/CCA  (Injection) 

Planned  Date:  03NOV201 0  091 8Z 
Actual  Date  03NOV201 0  0952Z 

Injector  EXPCEN 

Location 

Description 

Ground  strike  with  CAS/CCA 

Yl  03.03.A05  Marine  blocking  (Action) 

Planned  Date:  03NOV201 0  1 007Z 
Actual  Date 
Duration  0m 

Location 

Description 

USMC  in  JCATS  positioned  south  of  Terrorist  Camp  in  Blocking  position.  Terrorists  (both  in  JCATS  and 
VBS2-GBR)  moving  south  from  the  camp  will  be  engaged  by  USMC. 

|3  03.03.A06  MEDEVAC  (Action) 

Planned  Date:  03NOV2010  1007Z  State  Cancelled 

Actual  Date  Protagonist 

Duration  0m  Excon  Cell  EXPCELL-DEU 

Location  Actors  JEMM,  JEMM, 

Description 

Evacuate  wounded  Spanish  infantry  in  VR-Forces  using  Pitch  Actors.  The  woundesoldier  will  be  in  the 
vicinity  of  the  ground  strike.  Exact  location  will  be  determined  based  on  the  ground  strike.  The  wounded 
soldier  can  be  evacuated  to  any  field  hospital  selected  by  EXPCELL-NLD. 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-NLD,  EXPCELL-ACT, 
EXPCELL-GBR,  EXPCELL-ESP, 
EXPCELL-FRA, 


State 

Protagonist 
Excon  Cell 
Actors 


Cancelled 

EXPCELL-ACT 
JEMM,  JEMM, 


IS  03.03.105  Marine  Blocking  Position  (Injection) 


Planned  Date: 

03NOV2010  1007Z 

State 

Cancelled 

Actual  Date 

Means 

PLEXComm  Radio 

Injector 

EXPCEN 

Coordinating 

Cell 

EXPCEN 
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Location 

Description 

Marine  blocking  position 

[g  03.03.106  MEDEVAC  (Injection) 

Planned  Date:  03NOV2010  1007Z 
Actual  Date 

Injector  EXPCEN 

Location 

Description 

MEDEVAC 


Receiver  EXPCELL-ACT,  EXPCELL-GBR, 


State  Cancelled 

Means  PLEXComm  Radio 

Coordinating  EXPCEN 

Cell 

Receiver  EXPCELL-ESP,  EXPCELL-DEU, 


03.04  Assault  Campaign  2  (Internet  with  booster)  (Storyline) 

Story 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 


The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 


03.04.001  MSG-068  NETN  Concept  and  Reference  Federation  (Intended  Storyline  Outcome) 

Description 

Prove  that 

-  MSG-068  NETN  concept  is  feasible 

-  MSG-068  NETN  Reference  Federation  Architecture  is  practical 


03.04.A01  UAV  Recce  ( Action ) 

Planned  Date: 

02NOV2010  1300Z 

State 

Completed 

Actual  Date 

02NOV2010  1300Z 

Protagonist 

Duration 

2h 

Excon  Cell 

EXPCELL-AC1 

Location 

Actors 

JEMM,  JEMM, 

Description 

The  UAV  Reconnaissance  vignette  demonstrates  the  use  of  RPR-FOM  based,  platform  level,  virtual 
simulation  VBS2  and  constructive  simulation  JCATS.  Radio  simulation  is  used  to  model  communication 
between  UAV  operator  and  ground  commander.  JCATS  stimulates  VBS2  with  entities  representing  the 
terrorist  camp  buildings,  vehicles  and  individual  humans.  VBS2  simulates  UAV  and  generates  a  UAV 
feed  over  the  area  including  visualization  of  JCATS  generated  entities. 

Fly  a  predator  in  VBS2(NLD).  Initial  location  for  the  predator  is  57.388402,  18.189365,  2000. 


Move  entities  in  JCATS  around  buildingl  (58.643177,  15.316343,  0)  and  building  2  (58.639517, 
15.311118,0) 


03.04.101  UAV  Recce  (Injection) 

Planned  Date:  02NOV201 0  1 300Z 
Actual  Date  02NOV201 0  1 300Z 

Injector  EXPCEN 

Location 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-NLD,  EXPCELL-ACT, 
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Description 

UAV  is  tasked  to  monitor  the  area.  JCATS  entities  are  reflected  in  VBS2. 


03.04.A02  Implement  air  strikes  by  using  VBS2-NLD,  VBS2-UK  and  JPECT  (Action) 


Planned  Date:  02NOV201 0  1 31 7Z 

State 

Completed 

Actual  Date  02NOV201 0  1 31 7Z 

Protagonist 

Duration  15m 

Excon  Cell 

EXPCELL-ACT 

Location 

Actors 

JEMM,  JEMM,  JEMM,  JEMM, 

Description 

Air  missions  flying  in  JPECT  strike  the  terrorist  camp  in  JCATS. 

Select  any  type  of  aircraft  and  ammunition.  UAVs  in  VBS2  UK  and  VBS2  NLD  observe. 


03.04.102  Air  Strike  (Injection) 


Planned  Date:  02NOV201 0  1 31 5Z 
Actual  Date  02NOV201 0  1 31 7Z 
Injector  EXPCEN 

Location 

Description 

Air  strike  ordered  and  executed 

ugj  03.04.A03  Air  refuel  (Action) 

Planned  Date:  02NOV201 0  1 329Z 
Actual  Date  02NOV201 0  1 329Z 
Duration  15m 

Location 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-NLD,  EXPCELL-ACT, 
UNKNOWN,  EXPCELL-GBR, 


State  Completed 

Protagonist 

Excon  Cell  EXPCELL-SWE 

Actors  JEMM,  JEMM,  JEMM, 


Description 

A  request  for  air  refule  is  comming  from  an  aircraft  modelled  by  JTLS  in  the  south  of  Bogaland.  A  tanker 
aircraft  in  Orque  offers  supply  service  to  this  aircraft  and  the  services  are  supplied,  and  both  aircraft 
goes  on  their  way.TYR  is  passive. 


03.04.103  Air  Refuel  (Injection) 

Planned  Date:  02NOV201 0  1 332Z 
Actual  Date  02NOV201 0  1 329Z 

Injector  EXPCEN 

Location 

Description 

Air  refuel 


State  Injected 

Means  PLEXComm  Radio 

Coordinating  EXPCEN 

Cell 

Receiver  EXPCELL-ACT,  EXPCELL-SWE, 

EXPCELL-FRA, 


i  03.04.104  Ground  strike  2  (Aggregate)  (Injection) 


Planned  Date:  02NOV201 0  1 344Z 
Actual  Date  02NOV201 0  1 349Z 

Injector  EXPCEN 

Location 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

E-MAIL 

EXPCEN 

EXPCELL-ACT,  EXPCELL-SWE, 
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EXPCELL-FRA, 


Description 

Ground  strike  (aggregate) 


iu£j  03.04.A04  Ground  strike  (aggregate)  (Action) 

Planned  Date:  02NOV201 0  1 349Z 
Actual  Date  02NOV201 0  1 353Z 
Duration  15m 

Location 


State 

Protagonist 
Excon  Cell 
Actors 


Completed 

EXPCELL-FRA 

JEMM,  JEMM,  JEMM,  JEMM, 


Description 

Terrorists  are  in  JCATS  and  in  the  camp  area. 

Aggregate  units  in  TYR,  WAGRAM  and  JTLS  (select  appropriate  one  from  your  ORBAT)  engage 
terrorist  camp. 


J<j  03.04.105  Marine  Blocking  (Injection) 

Planned  Date:  02NOV2010  1404Z 
Actual  Date  02NOV2010  1410Z 
Injector  EXPCEN 

Location 

Description 

Marine  blocking 

03.04.A05  Marine  blocking  (Action) 

Planned  Date:  02NOV2010  1410Z 
Actual  Date  02NOV2010  1412Z 
Duration  0m 

Location 


State  Injected 

Means  PLEXComm  Radio 

Coordinating  EXPCEN 
Cell 

Receiver  EXPCELL-NLD,  EXPCELL-ACT, 


State  Completed 

Protagonist 

Excon  Cell  EXPCELL-ACT 

Actors  JEMM,  JEMM, 


Description 

USMC  in  JCATS  positioned  south  of  Terrorist  Camp  in  Blocking  position.  Terrorists  (both  in  JCATS  and 
VBS2-NLD)  moving  south  from  the  camp  will  be  engaged  by  USMC. 


03.04.106  Hostage  Situation  (Injection) 

Planned  Date:  02NOV2010  1425Z 
Actual  Date  02NOV2010  1457Z 
Injector  EXPCEN 

Location 

Description 

Hostage  taken  and  situation  resolved 

I 03.04.A06  Hostage  situation  (Action) 

Planned  Date:  02NOV2010  1457Z 
Actual  Date  02NOV201 0  1 500Z 
Duration  0m 

Location 


State  Injected 

Means  PLEXComm  Radio 

Coordinating  EXPCEN 
Cell 

Receiver  EXPCELL-SWE,  EXPCELL-DEU, 


State  Completed 

Protagonist 

EXPCELL-DEU 
Actors  JEMM,  JEMM, 
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Description 

TYR  will  request  the  transport  a  group  of  hostages  held  outside  the  terrorist  camp  and  Kora  will  provide 
the  transport. 


03.04.A09  MEDEVAC  (Action) 

Planned  Date:  02NOV201 0  1 508Z 
Actual  Date  02NOV201 0  1 508Z 
Duration  Om 

Location 


State  Completed 

Protagonist 

Excon  Cell  EXPCELL-DEU 

Actors  JEMM,  JEMM, 


Description 

Evacuate  wounded  Spanish  infantry  in  VR-Forces  using  German  medevac  units. in  Kora.  The 
woundesoldier  will  be  in  the  vicinity  of  the  ground  strike.  Exact  location  will  be  determined  based  on  the 
ground  strike.  The  wounded  soldier  can  be  evacuated  to  any  field  hospital  selected  by  EXPCELL-DEU. 


03.04.107  MEDEVAC  ( Injection ) 

Planned  Date: 

02NOV2010  1512Z 

State 

Injected 

Actual  Date 

02NOV2010  1508Z 

Means 

PLEXComm  Radio 

Injector 

EXPCEN 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

EXPCELL-ESP,  EXPCELL-DEU, 

Description 

execute  medevac  injection 

03.04.R01  Report  about  the  results  of  Campaign  2  with  Booster  (Return) 


Planned  Date: 

03NOV2010  1100Z 

State 

Draft 

Actual  Date 

Sender 

EXPCELL-ACT 

Receiver 

EXPCEN 

Description 

Report  about  the  results  of  Campaign  2  with  Booster. 


03.04.108  Ammunition  resupply  (Injection) 

Planned  Date:  04NOV201 0  1 000Z 
Actual  Date  04NOV201 0  1 004Z 
Injector  EXPCEN 

Location 

Description 

Ammunition  resuply 

03.04.A08  Ammunition  resuply  (Action) 

Planned  Date:  04NOV201 0  1 004Z 
Actual  Date  04NOV201 0  1 005Z 
Duration  15m 

Location 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 

EXPCELL-ACT,  EXPCELL-FRA, 


State  Completed 

Protagonist 

Excon  Cell  EXPCELL-FRA 

Actors  JEMM,  JEMM, 


Description 

JCATS  requests  an  ammunition  resupply  and  WAGRAM  provides  that. 
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OBSERVATION  TASK  REPORT 


Storyline  Observation  Tasks 


__jl  stOROI  (Storyline  Observation  Task) 


Observe  and  report  the  following  to  EXPCELL-NC3A  and  EXPCEN: 

-  Bandwidth  utilization 

-  Roundtrip  delay 

-  Throughput 

-  Jitter 

Date  28  Oct  2010  till  28  Oct  2010 


Training  Audience: 

Observers: 

Observer  Teams: 
Response  Cell 
Observers: 


none 

ObserverDEU,  ObserverGBR,  Olssan  Lennart,  Peter  Langeslag,  Robert 

Forsgen,  Roger  Jansen,  Vladimir  Manda 

none 

EXPCELL-FRA,  EXPCELL-ACT,  EXPCELL-DEU,  EXPCELL-GBR, 
EXPCELL-NLD,  EXPCELL-NC3A,  EXPCELL-SWE 


01  02  Establish  CFBLNet  and  the  Internet  connections  (Storyline) 

All  nations  and  NATO  organizations  connect  to  CFBLNet. 

EOQ1  Secure,  persistent,  on-demand  training  capability  (Primary  Training  Objective) 

To  validate  MSG-068  recommendations  for  a  secure,  persistent,  on-demand  training  capability  that 
integrates  national  centres  and  NATO 

EQ05  Technical  standards  (Secondary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


STOR02  (Storyline  Observation  Task) 


Report  the  follwoing  about  the  CFBLNet  performance  throughout  the  experiment: 

-  Utilization 

-  Round  trip  delay 

-  Throughput 

-  Jitter 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 


28  Oct  2010  till  05  Nov  2010 

EXPCELL-NC3A 

Edgar  Harnsen,  Vladimir  Manda 

none 


Response  Cell 
Observers: 


EXPCELL-NC3A 


PI  Q3  Manage  and  monitor  CFBLNet  infrastructure  (Storyline) 

NC3A  manages  and  monitors  the  CFBLNet  infrastructure. 

EOQ1  Secure,  persistent,  on-demand  training  capability  (Primary  Training  Objective) 

To  validate  MSG-068  recommendations  for  a  secure,  persistent,  on-demand  training  capability  that 
integrates  national  centres  and  NATO 
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jj  Observation  59 

JTLS  Observe  that  initial  joining  the  federation  is  perceived  as  being  slower  /  more  sluggish 
compared  to  federation  join  the  day  before.  Perception  is  not  backed  by  data.  After  join  everything 
'feels'  normal. 

CFBLNet  is  backbone  is  NGCS.  Yesterdays  configuration:  No  CFBLNet,  Internet,  VPN  with 
booster. 

NLVC  also  reported  problems  when  joining.  After  joining  all  felt  normal. 

n  03  Nov  2010 

ate‘  08:03:00 

Observer:  ANALYSTTECH4 

TECHNICAL 

Observer  Role:  ANALYSIS  AND 

OBSERVATION 


j|  Observation  66 

CFBLNet  connection  to  TNO  has  been  lost. 

Loss  of  connection  was  related  to  asymmetry  in  network  performance. 

Network  router  has  been  rebooted  and  the  connection  was  restored,  to  be  lost  again  at  09:08Z. 

Up  again  at  09:12Z 

Lost  at  09:1 5Z 

09:16Z  all  connections  lost 

09:18Z  all  connections  back  up 

CFBLNet  technical  staff  are  investigating  the  problem 

Date: 

Observer: 

Observer  Role: 


lj  Observation  1 03 

Procedures  around  CFBLNet  connectivity  are  perceived  as  being  too  burocratic  and  irresponsive. 
There  are  too  many  documents  and  complicated  forms  involved;  it  takes  a  long  time  to  receive 
reply  to  questions. 

National  POC  keep  changing,  it  is  very  hard  to  know  who  is  the  POC  at  any  given  time. 

n  04  Nov  2010 

08:53:00 

Observer:  ANALYSTTECH4 

TECHNICAL 

Observer  Role:  ANALYSIS  AND 

OBSERVATION 


03  Nov  2010 
08:23:00 

ANALYSTTECH4 

TECHNICAL 
ANALYSIS  AND 
OBSERVATION 


_j|  Observation  1 04 

NGCS  as  service  provider  is  perceived  as  showing  slow  response  time. 
Requests  for  support  have  taken  more  than  one  week  to  give  an  initial  reply. 
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Feedback  with  actual  measurements  is  not  given. 

Date: 

Observer: 

Observer  Role: 


Observation  105 

During  a  CFBLNet  switch  from  NGCS  to  VPN  tunnel  backbone,  where  physical  connections 
between  sites  were  lost,  the  booster  functionality  managed  to  keep  the  federation  up  and  running; 
federation  execution  has  been  succesfully  resumed  after  the  physical  connections  had  been 
reestablished. 

This  was  observed  both  with  controlled  and  uncontrolled  network  interruptions. 

n  04  Nov  2010 

08:59:00 

Observer:  ANALYSTTECH4 

TECHNICAL 

Observer  Role:  ANALYSIS  AND 

OBSERVATION 


04  Nov  2010 
08:56:00 

ANALYSTTECH4 

TECHNICAL 
ANALYSIS  AND 
OBSERVATION 


jj  Observation  1 06 

CFBLNet  has  been  used  in  two  different  configurations  with  regards  to  the  underlying 
infrastructure:  Internet  and  NGCS. 

Latency  and  bandwidth  data  have  been  recorded  and  need  to  be  supplied  and  analyzed. 
As  an  average: 

Internet  latency 

35  ms  roundtrip  time  from  JFTC  to  TNO 

65  ms  roundtrip  time  from  JFTC  to  DSTL 

1 10  ms  roundtrip  time  from  JFTC  to  Paris 

Numbers  have  been  recorded  using  the  pingplotter  software. 

Internet  bandwidth 
2Mb/s  between  JFTC  and  DSTL 
4Mb/s  between  JFTC  and  TNO 
unknown  for  Paris  (<  IMb/s) 

Numbers  have  been  recorded  using  the  iperf  software. 

NGCS  latency 

200  ms  roundtrip  time  from  JFTC  to  TNO 

220  ms  roundtrip  time  from  JFTC  to  DSTL 

300  ms  roundtrip  time  from  JFTC  to  Paris 

Numbers  have  been  recorded  using  the  pingplotter  software. 

NGCS  bandwidth 
1.2Mb/s  between  JFTC  and  DSTL 
2Mb/s  between  JFTC  and  TNO 
unknown  for  Paris  (<  IMb/s) 
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Numbers  have  been  recorded  using  the  iperf  software. 

Date: 

Observer: 


Observer  Role: 


04  Nov  2010 
09:02:00 

ANALYSTTECH4 

TECHNICAL 
ANALYSIS  AND 
OBSERVATION 


jj  Observation  1 07 

There  has  been  no  perceived  overhead  in  terms  of  performance  due  to  the  extra  cryptographic 
equipment  in  CFBLNet  over  Internet  compared  to  the  configuration  using  Internet  only. 


Detailed  data  have  been  recorded  and  can  be  analyzed  afterwards. 

Date: 

Observer: 


Observer  Role: 


04  Nov  2010 
09:10:00 

ANALYSTTECH4 

TECHNICAL 
ANALYSIS  AND 
OBSERVATION 


'  STOR03  (Storyline  Observation  Task) 

Observe  the  technical  quality  of  the  environment. 
Prepare  and  hand  over  a  questionaire  to  the  audience. 
Analyze  and  report  the  results  of  the  questionaire. 

Date 

Training  Audience: 

Observers: 

Observer  Teams: 

Response  Cell 
Observers: 


04  Nov  2010  till  04  Nov  2010 
C-IED  Audience 
CIEDOBSERVER 
none 

EXPCELL-ACT 


02  02  C-IED  (Storyline) 

Two  subject  matter  experts  (SME)  will  be  tasked  by  HQ-SACT  and  one  staff  officer  will  be  tasked  by 
JFTC  for  this  incident.  These  SMEs  and  the  staff  officer  will  act  as  the  trainers  for  a  distributed  C-IED 
training  using  VBS2-NATO  as  the  training  tool.  Apart  from  that  10  trainees  will  be  assigned  by  HQ- 
SACT.  Trainers  will  be  in  EXPCELL-ACT  in  Bydgoszcz,  and  the  trainees  will  stay  in  Norfolk.  All  the 
data  communications  will  be  via  the  Internet. 

EQ06  Distributed  training  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  distributed  training  involving  national  and  NATO  C2  and 
simulation  systems 


STOR04  (Storyline  Observation  Task) 

Observe  the  following: 

-  The  time  required  to  start  the  federation 

-  Execution  time  (sim  time  real  time  ratio  that  can  e  achieved) 

-  Crashes  and  reasons  for  crashes 
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Prepare  a  questionarie  about  the  usefulness  of  the  NLVC  concept  and  federation,  and  ask  NLVC 
experiment  audience  to  complete  it. 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


04  Nov  2010  till  04  Nov  2010 
NLVC  Audience 

Clive  Wood,  Jaap  Middelburg,  NLVCSPV1,  NLVCSPV2 
none 

EXPCELL-NLD 


02  03  NLVC-1  (Storyline) 

Forward  observers  located  in  JFTC  (EXPCELL-ACT)  and  using  FACSIM  FAC  station  controls  air 
mission  (air  to  ground  attack)  that  fly  in  FACSIM  (FI  6).  FLAMES  (FI  8)  in  JFTC  (EXPCELL-ACT 
controlled)  fly  combat  air  patrol.  3  VBS2-VTK  UAVs  observe  villiage  (1  X  GBR  @  DSTL,  1  X  NLD  @ 
TNO,  1  X  JWC  UAV  but  controlled  from  JFTC).  Targets  are  armed  vehicles  in  the  villiage  and  any 
escaping  vehicles.  The  objective  is  to  demonstrate  that  NLVC  concept  and  federation  work  efficiently, 
make  observations  on  the  technical  performance/procedures  for  NLVC,  and  determine  utility  for  the 
NLVC  capabiltiy  to  support  Distributed  Training  and  Exercises. 

EQ06  Distributed  training  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  distributed  training  involving  national  and  NATO  C2  and 
simulation  systems 

EQ05  Technical  standards  (Secondary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

EOQ4  Multi-granularity  (Secondary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  multi-granularity 


jj  Observation  2 

Federation  started  in  2  min  35  sec. 

Date: 

Observer: 

Observer  Role: 


29  Oct  2010  11:52:00 
CAYIRCIE 
CHIEF  EXPCEN 


jj  Observation  1 24 

VBS2  NATO  crashed  when  vehicle  got  destroyed. 

Date:  04  Nov  2010  13:42:00 

Observer:  ANALYSTTECH3 

Observer  Role:  TECHNICAL  OBSERVATION  AND  ANALYSIS 


njJ  Observation  125 

VBS2  crash  during  NLVC  game.  Aircraft  fired  on  vehicle, 
lines  from  VBS2  LVC  Error  log 
[LVCGame]  11/04/10  12:39:08  ERROR 

(HLA1516E::RPR_COMMON::AntennaPatternStruct::unmarshal)  **BufferUnderrun** 
AntennaPatternStruct  expects  4  bytes,  found  0 
[LVCGame]  11/04/10  12:39:08  ERROR 

(HLA1516E::RPR_COMMON::AntennaPatternStruct::unmarshal)  **BufferUnderrun** 
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AntennaPatternStruct  expects  4  bytes,  found  0 

[LVCGame]  11/04/10  12:40:36  WARNING  (LVCGame_API::entityCreated)  VBS->LVC  No 
mappings  found  for  entity  type  '#destructioneffects' 

[LVCGame]  11/04/10  12:40:36  WARNING  (LVCGame_API::entityCreated)  VBS->LVC  No 
mappings  found  for  entity  type  '#objectdestructed' 

[LVCGame]  11/04/10  12:51:31  WARNING  (LVCGame_API::entityCreated)  VBS->LVC  No 
mappings  found  for  entity  type  '#destructioneffects' 

[LVCGame]  11/04/10  12:51:31  WARNING  (LVCGame_API::entityCreated)  VBS->LVC  No 
mappings  found  for  entity  type  '#objectdestructed' 

[LVCGame]  11/04/10  12:52:03  INFO  (HLA1516E::HLAManager::resign)  Resigning  from 
federation... 

[LVCGame]  11/04/10  12:52:03  INFO  (HLA1516E::HLAManager::resign)  Resigned  from 
federation! 

Date:  04  Nov  2010  14:53:00 

Observer:  BROWNA 

Observer  Role:  JEMM  ADMIN 


jj  Observation  1 26 
NLVC  federation  observation. 

Vehicles  disappearing  in  VBS2. 

HLA  config  change: 

hla1516e.deleteTimeout  =  6000 

changed  to 

hla1516e.deleteTimeout  =  0 

This  is  the  time  in  miliseconds  to  wait  for  updates  from  a  remote  entity  before  it  automatically  gets 
deleted,  zero  turns  this  off. 

Date:  04  Nov  2010  14:57:00 

Observer:  BROWNA 

Observer  Role:  JEMM  ADMIN 


_J,  stoR05  /Sf oryline  Observation  Task) 

Report  about  both  the  following  technical  and  operational  issues: 

Technical: 

-  The  time  required  to  start  the  experiment 

-  The  execution  speed  (the  simulation  time  to  real  time  ratio  that  can  be  achieved) 

-  The  overhead  of  federating  instead  of  running  the  same  scenario  at  a  single  simulation 


Operational 

-  The  realism 

-  The  training  value 

Date 

Training  Audience: 
Observers: 
Observer  Teams: 


04  Nov  2010  till  04  Nov  2010 
Logistics  Audience 
ObserverDEU 
none 
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EXPCELL-ESP,  EXPCELL-ACT,  EXPCELL-DEU 


02  01  L<>gistics  (MEDEVAC)  (Storyline) 

Two  troops  modeled  in  VR-Forces  by  EXPCELL-ESP  are  wounded.  A  medical  evacuation  plan  is 
developed  by  the  operational  people  in  EXPCELL-ACT  send  their  plan  to  MEDEVAC  responce  cell  in 
EXPCELL-DEU.  Then  EXPCELL-DEU  mplements  this  plan  in  KORA  to  evacuate  the  wounded  troops 
modelled  in  VR-Forces.  All  incident  is  also  observed  in  the  other  models  (i.e.,  JCATS,  JTLS,  TYR, 
VBS2). 

EQ06  Distributed  training  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  distributed  training  involving  national  and  NATO  C2  and 
simulation  systems 

EQ03  Distributed  simulation  integrating  NATO  and  national  M&S  capabilities  (Secondary  Training 
Objective) 

To  validate  MSG-068  recommendations  for  distributed  simulation  integrating  NATO  and  national  M&S 
capabilities 


STOR06  (Storyline  Observation  Task) 


Observe  and  report  the  following: 

-  Orque  can  provide  and  WAGRAM  can  consume  Convoy  service 

-  Orque  can  provide  and  VR-Forces  consume  Convoy  service 

-  JTLS  NETN  surface  vessels  are  reflected  in  Orque 

-  VR-Forces  aggregate  units  are  reflected  in  WAGRAM  and  JTLS 

-  WAGRAM  units  are  reflected  in  VR-Forces 

-  JTLS  units  are  reflected  in  VR-Forces 

-  Orque  units  are  reflected  in  JTLS 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 


02  Nov  2010  till  02  Nov  2010 
none 

Ellen  Roland,  Enrique  Banales,  Jose  Ruiz 
none 


Response  Cell 
Observers: 


EXPCELL-ESP,  EXPCELL-FRA,  EXPCELL-ACT 


03  01  Assault  Campaign  1  (Internet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 


EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


’03.01.101 

Sea  lift  (Injection) 

Planned  Date: 

02NOV2010  0858Z 

State 

Injected 

Actual  Date 

02NOV2010  0856Z 

Means 

PLEXComm  Radio 

Injector 

EXPCEN 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

Description 
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Sea  lift  of  forces 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  sea  lift. 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


jj  Observation  5 


JTLS  observe  that  the  federation  is  locked  up  and  we  don't  know  if  the  issue  is  being  addressed. 


Date: 

Observer: 

Observer  Role: 


02  Nov  2010  08:04:00 
ANALYSTTECH3 

TECHNICAL  OBSERVATION  AND 
ANALYSIS 


jj  Observation  6 


JTLS  observe  that  there  are  JTLS  units  and  ships  published  but  there  is  no  action  for  them. 
Consulted  with  EXPCEN/Erdal  and  the  guidance  is  that  in  Campaign  1  there  is  no  activity,  but 
there  can  be  some  in  the  other  campaigns. 


Date: 

Observer: 

Observer  Role: 


02  Nov  2010  08:05:00 
ANALYSTTECH3 

TECHNICAL  OBSERVATION  AND 
ANALYSIS 


jj  Observation  8 


JTLS  HLA  component  (HIP)  came  down  while  decoding  an  entity  for  an  ASCII  dump 


Date: 

Observer: 

Observer  Role: 


02  Nov  2010  09:00:00 
ANALYSTTECH3 

TECHNICAL  OBSERVATION  AND 
ANALYSIS 


|||  Observation  21 

The  first  attempt  was  not  successful.  Not  all  the  federates  managed  to  join. 

After  changing  the  order  (JTLS,  Alliagtor,  VR-Forces)  the  ferederation  got  going. 

Date:  02  Nov  2010  10:31:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 


jj  Observation  1 1 6 

Remark  1  :  ORQUE  received  a  Convoy  request  from  WAGRAM 
Provider  is  "MISTRAL"  and  Consumer  is  "244EEI" 

Remark  2  :  Some  incompatibilities  between  ALLIGATOR  and  VRFORCE  are  noticed.  Request 
can't  be  acheived. 

Some  local  test  were  needed  to  continue  the  incident  "Sealift". 

Remark  3  :  Aicraft  and  surface  vessel  from  JTLS  were  reflected  in  ORQUE  and  WAGRAM 
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Remark  4  :  Aggregate  units  from  VRFORCE  were  not  reflected  in  ORQUE  and  ORQUE 


Date: 

Observer: 

Observer  Role: 


04  Nov  2010  10:49:00 
OBSERVERFRA 

OBSERVER  AND  ANALYST  IN 
EXPCELL-FRA 


STOR07  (storyline  Observation  Task) 

Repeat  STOR6.  Is  there  any  difference  comparing  to  your  observations  during  STOR6.  Observe  the 
differences  also  in  performance  (i.e.,  delay,  and  simulation  speed  that  can  be  achieved). 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


03  Nov  2010  till  03  Nov  2010 
none 

Ellen  Roland,  Enrique  Banales,  Jose  Ruiz 
none 

EXPCELL-ESP,  EXPCELL-FRA,  EXPCELL-ACT 


03  03  Assault  Campaign  1  (CFBLNet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 


The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 


EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

v  03.03.101  Sea  lift  (lnJection) 

Injected 

PLEXComm  Radio 
EXPCEN 


Description 

Sea  lift  of  forces 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


Planned  Date: 
Actual  Date 
Injector 

Location 


03NOV2010  0745Z 
03NOV2010  0745Z 
EXPCEN 


State 

Means 

Coordinating 

Cell 

Receiver 


Start  sea  lift. 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


jj  Observation  58 

PLEXCOMM  was  not  set  with  correct  parameters,  operators  were  transmitting  on  the  wrong 
frequencies.  Likely  due  to  missing  training 

Date:  03  Nov  2010  08:00:00 

Observer:  CH I EFAN  ALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 
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jj  Observation  70 

JTLS  successfully  published  3  ships. 

JTLS  reflected  VR-Forces  and  ORQUE  units. 

JTLS  air  missions  successfully  published  and  reflected  in  GE  Adapter. 

Date:  03  Nov  2010  09:53:00 

Observer:  ANALYSTTECH3 

Observer  Role:  TECHNICAL  OBSERVATION  AND  ANALYSIS 

jj  Observation  7 1 

Air  mission  have  to  have  pre-defined  names  to  be  recognized  in  the  federation.  There  is  no 
flexibility. 

Date:  03  Nov  2010  09:57:00 

Observer:  ANALYSTTECH3 

Observer  Role:  TECHNICAL  OBSERVATION  AND  ANALYSIS 

jj  Observation  76 

Position  of  VR-Forces  entities  (namely  Sea  lift  convoy)  seemed  to  be  in  a  different  location  than 
the  one  planned  for  the  injection. 

Date:  03  Nov  2010  12:26:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

jj  Observation  1 1 8 

Remark  1  :  ORQUE  received  a  Convoy  request  and  acheive  Transport  with  WAGRAM 
Provider  is  "MISTRAL"  and  Consumer  is  "244EEI" 

Remark  2  :  ORQUE  received  a  Convoy  request  and  negociate  the  offer  with  VRFORCE 
Provider  is  "TONNERRE"  and  Consumer  is  "BIMZ31/l/3Coy" 

Moving  of  "BIMZ31/l/3Coy"  to  the  point  of  On  Board  is  to  long  to  acheive  Transport. 

Remark  3  :  Aicraft  and  surface  vessel  from  JTLS  were  reflected  in  ORQUE  and  WAGRAM 

Remark  4  :  Aggregate  units  from  VRFORCE  were  reflected  in  ORQUE. 

Date:  04  Nov  2010  10:53:00 

Observer:  OBSERVERFRA 

Observer  Role:  OBSERVER  AND  ANALYST  IN  EXPCELL-FRA 


\  STOR08  (Storyline  Observation  Task) 

Oserve  the  following: 

-  JCATS  entities  are  reflected  in  VBS2-UK 

-  VBS2-UK  entities  are  reflected  in  JCATS 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 


02  Nov  2010  till  02  Nov  2010 
none 

Andy  Brown,  ObserverGBR 
none 

EXPCELL-ACT,  EXPCELL-GBR 
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Observers: 


03  01  Assault  Campaign  1  (Internet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 


The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 


EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


03  01  102  WAV  Recce  (Injection) 

Planned  Date:  02NOV2010  091 1Z 
Actual  Date  02NOV201 0  0909Z 

Injector  EXPCEN 

Location 

Description 

UAV  is  tasked  to  monitor  the  area 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 


Start  the  UAV  mission. 


***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


jj  Observation  10 

2  different  UAVs  managed  by  2  different  VBS2  (TNO  &  UK)  flying  together  and  seeing  each  other 
in  a  single  federation 

Date:  02  Nov  2010  09:26:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 


jj  Observation  23 

JCATS  managed  to  properly  reflect  the  UAVs  uppdated  by  VBS2. 

One  of  the  objects  in  JCATS  (a  plain  terrorist)  could  not  be  presented  and  shown  properly 
because  of  a  mapping  problem  in  JCATS 

Date:  02  Nov  2010  10:34:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 


jJ  Observation  64 

VBS2  UAV  operator  was  able  to  see  the  entities  produced  by  JCATS  and  to  identify  9  vehicles, 
(represented  as  pick-up  trucks,  Jeeps  and  small  vans). 

Some  were  tracked  moving  around  the  camp.  Some  remained  stationary. 

The  moving  vehicles  stayed  on  or  near  the  roads  in  the  VBS2  terrain. 

Frame  rates  were  good 

Date:  02  Nov  2010  09:30:00 
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Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 


STOR09  (Storyline  Observation  Task) 

Repeat  STOR8.  Is  there  any  difference  comparing  to  your  observations  during  STOR8.  Observe  the 
differences  also  in  performance  (i.e.,  delay,  and  simulation  speed  that  can  be  achieved). 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


03  Nov  2010  till  03  Nov  2010 
none 

Andy  Brown,  ObserverGBR 
none 

EXPCELL-ACT,  EXPCELL-GBR 


03  03  Assau,t  Campaign  1  (CFBLNet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 


The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


03  03  102  ^AV  Racce  (Injection) 

Planned  Date:  03NOV201 0  0800Z 
Actual  Date  03NOV201 0  0804Z 

Injector  EXPCEN 

Location 

Description 

UAV  is  tasked  to  monitor  the  area 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


State  Injected 

Means  PLEXComm  Radio 

Coordinating  EXPCEN 

Cell 

Receiver 


Start  the  UAV  mission. 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


jJ  Observation  62 

JCATS  Entities  experimented  unplanned  firing  against  flying  objects  during  the  injection  (VBS2 
UK  controlled  UAV) 

Date:  03  Nov  2010  08:22:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

jj|  Observation  63 

VBS2  UK  were  able  to  see  JCATS  entities  -  Cultural  features,  platforms  and  lifeforms. 

Frame  rate  was  good.  Platforms  and  lifeforms  seen  to  move  at  reasonable  speeds. 
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JCATS  fire  and  detonations  NOT  seen  in  VBS2.  Possible  enumeration  mapping  issue  -  we  will 
investigate 

Date:  03  Nov  2010  09:02:00 

Observer:  OBSERVERGBR 

Observer  Role:  OBSERVER  AND  ANALYST  IN  EXPCELL-GBR 

j|  Observation  69 

VBS2-UK  entities  are  reflected  in  JCATS  as  planned 
Date:  03  Nov  2010  09:45:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 

ijJ  Observation  74 

JCATS  tried  to  shoot  down  a  UAV,  but  did  not  manage  (munition  mapping  problem) 

Date:  03  Nov  2010  10:47:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 


-A  STOR10  (Storyline  Observation  Task) 


Observe  the  following: 

-  Orque  munition  objects  are  reflected  in  JCATS 

-  Orque  munition  detonations  are  reflected  in  JCATS,  VBS2-UK  and  VBS2-NLD 

-  JCATS  updates  of  damage  state  of  cultural  features,  platforms  and  life  forms  are  reflected  in  VBS2 

-  VBS2-UK  and  VBS2-NLD  entities  are  reflected  in  JCATS  and  Orque 

-  JCATS  entities  are  reflected  in  VBS2-NLD  and  VBS2-UK 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


02  Nov  2010  till  02  Nov  2010 
none 

Andy  Brown,  Jose  Ruiz,  ObserverGBR,  Roger  Jansen 
none 

EXPCELL-FRA,  EXPCELL-ACT,  EXPCELL-GBR,  EXPCELL-NLD 


03  01  Assault  Campaign  1  (Internet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 

Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

03  01  103  Cruise  missile  (Injection) 

Planned  Date:  02NOV2010  0924Z  State  Injected 

Actual  Date  02NOV2010  0923Z  Means  PLEXComm  Radio 

Injector  EXPCEN  Coordinating  EXPCEN 


RTO-TR-MSG-068 
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Location 


Cell 

Receiver 


Description 

Cruise  strike  ordered  and  executed 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  cruise  missile  strike 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Observation  1 1 

Orque  to  speed  up  the  simulation  by  5  times 

Date:  02  Nov  2010  09:33:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

jj  Observation  61 

no  detonations  and  no  damage  to  entities  shown  in  the  interface-  either  from  VBS2  or  JCATS 

Date:  02  Nov  2010  09:43:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

.jjJ  Observation  1 3 

VBS2-NLD  saw  a  ground  vehicle  speeding  around  the  area. 

In  the  beginning  of  the  vignette  there  all  of  a  sudden  was  a  burning  vehicle  in  the  urban  area. 

VBS2-NLD  UAV/camera  seemed  to  lag  a  lot,  jumping  all  over  the  area.  When  Alligator  left  the 
federation  it  was  very  smooth  again. 

Date:  02  Nov  2010  09:43:00 

Observer:  ANALYSTTECH 


OBSERVATION  AND  AALYSIS  CHIEF  FOR  TECH 
ISSUES 


Observer  Role: 


jj  Observation  60 

VBS2  UK  UAV  operator  was  able  to  see  the  entities  produced  by  JCATS. 

Also  able  to  identify  9  vehicles,  (represented  as  pick-up  trucks,  Jeeps  and  small  vans). 

Some  were  tracked  moving  around  the  camp.  Some  remained  stationary. 

The  moving  vehicles  stayed  on  or  near  the  roads  in  the  VBS2  terrain. 

2  buildings  from  JCATS  also  received. 

There  were  4  dismounted  terrorists  spotted  also  -  these  were  moving  at  an  appropriate  speed. 
No  issues  with  simulation  speed. 

Date:  02  Nov  2010  09:05:00 


Observer: 


CHIEFANALYST 
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Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

J  Observation  1 7 

JCATS  did  not  reflect  the  missile  object  and  was  not  able  to  adjudicate  damage  against  the 
building;  both  issues  are  due  to  lack  of  data  mapping  in  JCATS.  This  has  been  corrected  for 
subsequent  testing. 

Date:  02  Nov  2010  10:07:00 

Observer:  OBSERVERUSA 

Observer  Role:  OT 


_jl  Observation  22 

When  ORQUE  joined  VBS2  UK  lost  simulation  speed  and  dropped  to  a  very  slow  frame  rate. 
JCATS  entities  -  platforms  and  lifeforms  and  cultural  features  all  appeared  in  VBS2 

No  visible  detonations,  no  damaged  entities  observed  or  recorded  in  our  entity  state  viewer  from 
the  detonation  event. 

There  was  1  damaged  entity  identified,  a  UAV  HERTI.13  which  was  from  the  TNO  VBS2  Cell,  - 
but  we  think  it  ran  out  of  fuel. 

This  appeared  as  a  K-Killed  unit  and  was  grounded. 

Date:  02  Nov  2010  10:36:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 


..jJ  Observation  25 

Munition  objects  are  not  reflected  in  JCATS 
Munition  detonations  are  not  reflected  in  JCATS 
A  UAV  (VBS2-NLD)  is  reflected,  but  not  moving 
Missiles  and  detonations  are  not  mapped  in  JCATS 

Date:  02  Nov  2010  10:37:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 


jj  Observation  1 1 5 

Remark  1  :  mobile  Plateform  from  JCATS  and  VBS2  are  reflect  in  ORQUE. 


Remark  2  :  Missile  use  for  ORQUE  fire  is  :  2.9.71.1.8.0.0 


Date:  04  Nov  2010  10:48:00 

Observer:  OBSERVERFRA 

Observer  Role:  OBSERVER  AND  ANALYST  IN  EXPCELL-FRA 


sTOR1 1  (Storyline  Observation  Task) 

Repeat  STOR10.  Is  there  any  difference  comparing  to  your  observations  during  STOR10.  Observe 
the  differences  also  in  performance  (i.e.,  delay,  and  simulation  speed  that  can  be  achieved). 

Date  03  Nov  2010  till  03  Nov  2010 

Training  Audience:  none 

Observers:  Andy  Brown,  Jose  Ruiz,  ObserverGBR,  Roger  Jansen 
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none 

EXPCELL-FRA,  EXPCELL-ACT,  EXPCELL-GBR,  EXPCELL-NLD 


03  03  Assault  Campaign  1  (CFBLNet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 


The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 


EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


03  03  103  Cru'se  missile  (Injection) 

Planned  Date:  03NOV2010  081 9Z 
Actual  Date  03NOV201 0  0903Z 

Injector  EXPCEN 

Location 

Description 

Cruise  strike  ordered  and  executed 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 


Start  cruise  missile  strike 


***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


Observation  3 
test 

Date: 

Observer: 
Observer  Role: 

^  Observation  4 
fghfghgfhgf 
Date: 

Observer: 
Observer  Role: 

Observation  12 


01  Nov  2010  12:59:00 

browna 

JEMM  admin 


01  Nov  2010  13:00:00 

browna 

JEMM  admin 


Date: 

Observer: 
Observer  Role: 


02  Nov  2010  09:43:00 
CHIEFANALYST 

CHIEF  ANALYST  AND  OBSERVER 


ij|  Observation  15 
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Date: 

Observer: 


02  Nov  2010  09:59:00 
CHIEFANALYST 


Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

_jj  Observation  65 

CFBLNet  went  down  for  line  issues.  When  stood  up  again,  the  federation  was  still  up  and  running 


Date: 

Observer: 


03  Nov  2010  09:32:00 
CHIEFANALYST 


Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

al  Observation  67 

VBS2-NLD  reflected  ground  units,  a  winged  UAV  and  a  helicopter. 

Munitions,  munition  detonations  and  damage  status  changes  were  not  visible  in  VBS2-NLD. 


03  Nov  2010  09:39:00 
ANALYSTTECH 


Date: 

Observer: 


Observer  Role:  OBSERVATION  AND  AALYSIS  CHIEF  FOR  TECH  ISSUES 

Observation  68 

Munition  objects  are  not  reflected  in  JCATS 

Munition  detonations  are  not  reflected  in  JCATS 

UAVs  (VBS2-NLD,  VBS2-UK  and  VBS2-JWC)  are  reflected  in  JCATS 

Missiles  and  detonations  are  not  mapped  in  JCATS 

Date:  03  Nov  2010  09:43:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 

Observation  72 

VBS2  was  able  to  see  JCATS  entities:  cultural  features,  platforms  and  lifeforms. 
Cruise  missile  was  logged  and  detonations  received  but  NOT  visualised. 

No  damaged  entities  recorded.  No  change  in  damage  states  of  JCATS  entities. 
Frame  rate  was  reduced  from  earlier  vignette  (UAV  recee) 

Date:  03  Nov  2010  10:17:00 

Observer:  OBSERVERGBR 

Observer  Role:  OBSERVER  AND  ANALYST  IN  EXPCELL-GBR 

ijJ  Observation  120 

Remark  1  :  mobile  Plateform  from  JCATS  and  VBS2  are  reflect  in  ORQUE. 

Remark  2  :  Missile  use  for  ORQUE  fire  is  :  2.9.71.1.8.0.0 
Date:  04  Nov  2010  10:53:00 

Observer:  OBSERVERFRA 

Observer  Role:  OBSERVER  AND  ANALYST  IN  EXPCELL-FRA 
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STOR12  (Storyline  Observation  Task) 


Observe  the  following: 

-  WAGRAM  indirect  fire  munition  detonations  are  reflected  in  JCATS,  VR-Forces,  VBS2-UK,  VBS2- 
NLD  and  FLAMES 

-  VR-Forces  platforms  are  rejected  in  VBS2-UK,  VBS2-NLD  and  FLAMES 

-  JCATS  entities/units  are  reflected  in  WAGRAM,  VR-Forces,  VBS2-NLD,  VBS2-UK  and  FLAMES 

-  VR-Forces  direct  fire  and  munition  detonation  is  reflected  in  WAGRAM,  JCATS,  VBS2  and  FLAMES 

-  JCATS  updates  of  damage  state  of  cultural  features,  platforms  and  live  forms  are  reflected  in  VBS2, 
VR-Forces  and  FLAMES 

-  VR-Forces  aggregate  units  are  reflected  in  JCATS,  WAGRAM  and  FLAMES 

-  VBS2-UK  fire  and  detonations  are  reflected  in  VR-Forces  and  FLAMES 

-  VR-Forces  updates  of  damage  state  is  reflected  in  VBS2-UK  and  FLAMES 

-  FLAMES  entities/units  are  reflected  in  WAGRAM,  VR-Forces,  VBS2-NLD,  VBS2-UK  and  JCATS 

-  FLAMES  fires/detonations  are  reflected  in  WAGRAM,  VR-Forces,  VBS2-NLD,  VBS2-UK  and  JCATS 

-  FLAMES  updates  of  damage  state  of  cultural  features,  platforms  and  life  forms  are  reflected  in  VR- 
Forces,  VBS2-NLD,  VBS2-UK  and  JCATS 

Date  02  Nov  201 0  till  02  Nov  2010 


Training  Audience: 

Observers: 

Observer  Teams: 
Response  Cell 
Observers: 


none 

Andy  Brown,  Enrique  Banales,  Jose  Ruiz,  ObserverGBR,  Roger  Jansen, 
Clive  Wood 


none 

EXPCELL-ESP,  EXPCELL-FRA,  EXPCELL-ACT,  EXPCELL-GBR, 
EXPCELL-NLD 


03  01  Assau,t  Campaign  1  (Internet  with  booster)  (Storyline) 
Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 


The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 


EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


Q3  Q-|  |04  Ground  Strike  with  CAS/CCA  (Injection) 


Planned  Date:  02NOV201 0  0938Z 
Actual  Date  02NOV201 0  0936Z 

Injector  EXPCEN 

Location 

Description 

Ground  strike  with  CAS/CCA 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 


Start  the  ground  strike  with  CAS/CCA 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


jj  Observation  54 
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VBS2  UK  &  NLD  controlled  UAVs  crashed  while  flying  in  the  same  federation 
Date:  02  Nov  2010  10:00:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

jj  Observation  1 8 

JCATS  again  has  difficulty  joining  the  federation. 

Date:  02  Nov  2010  10:1 1 :00 

Observer:  OBSERVERUSA 

Observer  Role:  OT 


njJ  Observation  55 

After  its  detonation,  munition  object  generated  by  FLAMES  didn't  move  away  from  federation 

Date:  02  Nov  2010  10:15:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 


jj  Observation  20 

VBS2-NLD  received  entities  and  airstrike  detonations  but  no  indirect  fire. 


Date: 

Observer: 

Observer  Role: 


02  Nov  2010  10:24:00 
ANALYSTTECH 

OBSERVATION  AND  AALYSIS  CHIEF  FOR 
TECH  ISSUES 


J  Observation  24 

VBS2  UK  initially  was  joined  to  the  federation.  Frame  rate  slowed  and  then  the  simulation 
froze. Unable  to  rejoin  the  federation  after  restarting  and  did  not  participate  in  the  injection. 

Date:  02  Nov  2010  10:38:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 


J  Observation  26 

JCATS  had  problems  connecting  to  the  federation.  It  was  resigned  from  the  federation  and  had  to 
restart. 

Bombs  are  not  removed  after  detonation  are  still  shown  by  JCATS. 

VR-Forces  direct  fire  and  detonations  are  reflected  by  JCATS. 

VR-Forces  aggregate  units  are  not  reflected  in  JCATS. 

FLAMES  entities  are  reflected  in  JCATS. 

FLAMES  detonations  are  reflected  in  JCATS. 

Date:  02  Nov  2010  10:57:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 


ijJ  Observation  28 

See  comments  in  STOR21  -  We  did  not  federate  with  WAGRAM 


RTO-TR-MSG-068 


G  -  51 


Appendix  2  to 

First  Impression  Report 

MSG-068  Experiment 


FLAMES  did  not  se  VBS2-UK  detonations  but  did  see  the  effect  of  the  air  to  air  collision 


Date: 

Observer: 
Observer  Role: 


02  Nov  2010  11:08:00 

SCENARIONLVC 

SCENARIO 


jj  Observation  29 

JCATS  entities  reflected  in  FLAMES 
VBS2-UK  entities  reflected  in  FLAMES 
VBS2-NL  enetities  refelected  in  FLAMES 
FLAMES  detonations  were  reflected  in  JCATS 
FLAMES  detoantion  were  refleted  in  VBS-2NL 
VBS2-UK  crashed  just  before  the  air  strike 

UAV  piolted  by  VBS2-UK  crashed  into  the  UAV  piloted  by  VBS2-NL 
VJCATS  entities  reflected  in  NLVC  Stealth  View  and  NLVC  Plan  View  Display 
VBS2-UK  entities  reflected  in  NLVC  Stealth  View  and  NLVC  Plan  View  Display 
VBS2-NL  enetities  refelected  in  NLVC  Stealth  View  and  NLVC  Plan  View  Display 
FLAMES  detonations  were  reflected  in  NLVC  Stealth  View  and  NLVC  Plan  View  Display 
FLAMES  detoantion  were  refleted  in  NLVC  Stealth  View  and  NLVC  Plan  View  Display 
VR-FORCES  entities  were  refelected  in  NLVC  Stealth  View  and  NLVC  Plan  View  Display. 
However  one  of  the  VR-FORCES  entities  was  positioned  on  top  of  a  tree. 

VR-FORCES  detonations  (direct  fire)  were  reflected  in  NLVC  Stealth  View  and  NLVC  Plan  View 
Display 

During  the  execution  there  seemed  to  be  a  problem  when  FACSIM  (using  DIS)  joined  the 
federation  through  a  Gateway  -  FLAMES  receieved  unexpected  UDP  traffic  and  eventually 
crashed. 

Since  the  test  FACSIM  has  joined  the  federation  through  the  gateway  as  expected  with  no 
additional  UDP  traffic. 

NOTE:  for  the  FAC  Vignette  on  Thursday  the  PlexComm  radios  need  to  be  on  the  same 
Federation  as  the  FACSIM,  VBS-2  NL,  FLAMES  etc  as  there  is  a  requirement  to  comunicate  to 
the  ASTi  Radios  (DIS)  at  TNO  and  JFTC. 

Date:  02  Nov  2010  1 1 :1 1 :00 

Observer:  SCENARIONLVC 

Observer  Role:  SCENARIO 

aJ  Observation  30 

JCATS  was  unable  to  process  some  of  the  VRForces  MunitionDetonation  Interactions  due  to  use 
of  non-ORBAT  munition  type,  e.g.  FiringObjectldentifier:  VRF24:129, 
munitiontype=2.2.225.2.1 .1 .0 

Date:  02  Nov  2010  1 1 :31 :00 

Observer:  OBSERVERUSA 

Observer  Role:  OT 

j  Observation  31 

Flames  updates  of  damages  are  reflected  in  JCATS 
Date:  02  Nov  2010  12:07:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 
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ij|  Observation  1 14 

Remark  1  :  Aggregate  units  and  Aircraft  from  all  simulation  were  reflected  in  WAGRAM. 


Remark  2  :  Munition  use  for  WAGRAM  fire  is  :  2.9.205.2.1 1 .0.0 
Date:  04  Nov  2010  10:48:00 

Observer:  OBSERVERFRA 

Observer  Role:  OBSERVER  AND  ANALYST  IN  EXPCELL-FRA 


!  STOR13  (Storyline  Observation  Task) 

Repeat  STOR12.  Is  there  any  difference  comparing  to  your  observations  during  STOR12.  Observe 
the  differences  also  in  performance  (i.e.,  delay,  and  simulation  speed  that  can  be  achieved). 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


03  Nov  2010  till  03  Nov  2010 
none 

Andy  Brown,  Enrique  Banales,  Jose  Ruiz,  ObserverGBR,  Roger  Jansen 
none 

EXPCELL-ESP,  EXPCELL-FRA,  EXPCELL-ACT,  EXPCELL-GBR, 
EXPCELL-NLD 


03  03  Assault  Campaign  1  (CFBLNet  with  booster)  (Storyline) 
Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 


The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 


EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

-*i  03  03  104  Grouncl  Strike  with  CAS/CCA  (Injection) 

Injected 

PLEXComm  Radio 
EXPCEN 


Description 

Ground  strike  with  CAS/CCA 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


Planned  Date: 
Actual  Date 
Injector 

Location 


03NOV2010  091 8Z 
03NOV2010  0952Z 
EXPCEN 


State 

Means 

Coordinating 

Cell 

Receiver 


Start  the  ground  strike  with  CAS/CCA 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


Observation  16 


Date: 

Observer: 


02  Nov  2010  10:00:00 
CHIEFANALYST 


RTO-TR-MSG-068 


G  -  53 


Observer  Role: 

ajJ  Observation  19 


Date: 

Observer: 
Observer  Role: 


_j|  Observation  33 


Appendix  2  to 
First  Impression  Report 
MSG-068  Experiment 
CHIEF  ANALYST  AND  OBSERVER 


02  Nov  2010  10:15:00 
CHIEFANALYST 

CHIEF  ANALYST  AND  OBSERVER 


Date: 

Observer: 
Observer  Role: 


02  Nov  2010  13:25:00 
CHIEFANALYST 

CHIEF  ANALYST  AND  OBSERVER 


uj  Observation  42 


02  Nov  2010  14:06:00 
CHIEFANALYST 

CHIEF  ANALYST  AND  OBSERVER 


Date: 

Observer: 
Observer  Role: 


jj  Observation  73 


VBS2-NLD  received  one  kind  of  detonations  and  damage  status  updates  on  entities.  Operator  of 
VBS2-NLD  could  not  tell  for  certain  if  it  was  WAGRAMs  indirect  fire  or  VR-forces  direct  fire  that 
caused  the  detonations,  but  the  operator  thinks  it  is  one  detonation  missing. 


Date: 

Observer: 

Observer  Role: 


03  Nov  2010  10:21:00 
ANALYSTTECH 

OBSERVATION  AND  AALYSIS  CHIEF 
FOR  TECH  ISSUES 


jj  Observation  75 

WAGRAM  indirect  fire  was  not  reflected  in  JCATS 

VR-Forces  direct  fire  and  munition  detonation  were  reflected  in  JCATS 

FLAMES  entities/fire  and  detonations/updates  of  damage  were  reflected  in  JCATS 

Date:  03  Nov  2010  10:49:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 


jj  Observation  1 1 9 

Remark  1  :  Aggregate  units  and  Aircraft  from  all  simulation  were  reflected  in  WAGRAM. 

Remark  2  :  Munition  use  for  WAGRAM  fire  is 

Date: 

Observer: 

Observer  Role: 


:  2.9.205.2.11.0.0 

04  Nov  2010  10:53:00 
OBSERVERFRA 

OBSERVER  AND  ANALYST  IN 
EXPCELL-FRA 


G  -  54 


RTO-TR-MSG-068 


Appendix  2  to 

First  Impression  Report 

MSG-068  Experiment 


-=6  STOR14  (St°ryline  Observation  Task) 


Observe  the  following: 

-  VBS2-UK  platform  and  life  form  are  reflected  in  JCATS 

-  JCATS  platforms  and  munition  detonations  are  reflected  in  VBS2-UK 

-  VBS2-UK  damage  states  are  reflected  in  JCATS 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 


02  Nov  2010  till  02  Nov  2010 
none 

Andy  Brown,  ObserverGBR 
none 


Response  Cell 
Observers: 


EXPCELL-ACT,  EXPCELL-GBR 


03  01  Assau,t  Campaign  1  (Internet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 

Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

03  01  105  Marine  Blocking  Position  (Injection) 

Planned  Date:  02NOV2010  0951Z  State  Cancelled 

Actual  Date  Means  PLEXComm  Radio 

Injector  EXPCEN  Coordinating  EXPCEN 

Cell 

Location  Receiver 

Description 

Marine  blocking  position 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

START  MARINE  BLOCKING  POSITION 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


■  STOR15  (Storyline  Observation  Task) 

Repeat  STOR15.  Is  there  any  difference  comparing  to  your  observations  during  STOR15.  Observe 
the  differences  also  in  performance  (i.e.,  delay,  and  simulation  speed  that  can  be  achieved). 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


03  Nov  2010  till  03  Nov  2010 
none 

Andy  Brown,  ObserverGBR 
none 

EXPCELL-ACT,  EXPCELL-GBR 


03  03  AssaL,tt  Campaign  1  (CFBLNet  with  booster)  (Storyline) 


RTO-TR-MSG-068 


G  -  55 


Appendix  2  to 

First  Impression  Report 

MSG-068  Experiment 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 


The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 


EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

03  03  105  Marine  Blocking  Position  (Injection) 


Planned  Date:  03NOV201 0  1 007Z 
Actual  Date 

Injector  EXPCEN 

Location 

Description 

Marine  blocking  position 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


State  Cancelled 

Means  PLEXComm  Radio 

Coordinating  EXPCEN 

Cell 

Receiver 


START  MARINE  BLOCKING  POSITION 


***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


STOR16  (Storyline  Observation  Task) 


Observe  the  following: 

-  KORA  can  provide  and  VR-Forces  consume  convoy  pattern 

-  VR-Forces  entities  are  reflected  in  Kora 

-  VR-Forces  aggregate  units  are  reflected  in  KORA 

-  KORA  entities  are  reflected  in  VR-Forces 

-  KORA  aggregate  units  are  reflected  in  VR-Forces 

Date  02  Nov  201 0  till  02  Nov  2010 


Training  Audience: 
Observers: 
Observer  Teams: 


none 

Enrique  Banales,  ObserverDEU 
none 


Response  Cell 
Observers: 


EXPCELL-ESP,  EXPCELL-DEU 


03  01  Assault  Campaign  1  (Internet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

03.01.106  MEDEVAC  (Injection) 


State 

Means 

Coordinating 


Cancelled 
PLEXComm  Radio 
EXPCEN 


G  -  56 


Planned  Date:  02NOV2010  0951 Z 
Actual  Date 

Injector  EXPCEN 


RTO-TR-MSG-068 


Appendix  2  to 

First  Impression  Report 

MSG-068  Experiment 

Cell 

Location  Receiver 

Description 

MEDEVAC 

Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  MEDEVAC 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


STOR17  (StoryHne  Observation  Task) 


Observe  the  following: 

-  PitchActors  can  provide  and  VR-Forces  consume  convoy  pattern 

-  VR-Forces  entities  are  reflected  in  PitchActors 

-  VR-Forces  aggregate  units  are  reflected  in  PitchActors 

-  PitchActor  entities  are  reflected  in  VR-Forces 

-  PitchActor  aggregate  units  are  reflected  in  VR-Forces 

Date  03  Nov  201 0  till  03  Nov  2010 


Training  Audience: 
Observers: 
Observer  Teams: 


none 

Enrique  Banales,  Olsson  Lennart 
none 


Response  Cell 
Observers: 


EXPCELL-ESP,  EXPCELL-NLD 


03  03  Assault  Campaign  1  (CFBLNet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 

Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

-»  03.03.106  MEDEVAC  (Injection) 

Planned  Date:  03NOV2010  1007Z  State  Cancelled 

Actual  Date  Means  PLEXComm  Radio 

Injector  EXPCEN  Coordinating  EXPCEN 

Cell 

Location  Receiver 

Description 

MEDEVAC 

Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  MEDEVAC 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


--L  STOR18  (Storyline  Observation  Task) 


RTO-TR-MSG-068 


G  -  57 


Appendix  2  to 

First  Impression  Report 

MSG-068  Experiment 


Observe  the  following: 

-  JCATS  entities  are  reflected  in  VBS2-NLD 

-  VBS2-NLD  entities  are  reflected  in  JCATS 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


03  Nov  2010  till  03  Nov  2010 
none 

Andy  Brown,  Roger  Jansen 
none 

EXPCELL-ACT,  EXPCELL-NLD 


03  02  Assault  Campaign  2  (CFBLNet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


3l  03.02J01 

UAV  Recce  (Injection) 

Planned  Date: 

03NOV2010  1300Z 

State 

Injected 

Actual  Date 

03NOV2010  1239Z 

Means 

PLEXComm  Radio 

Injector 

EXPCEN 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

Description 

UAV  is  tasked  to  monitor  the  area.  JCATS  entities  are  reflected  in  VBS2. 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  the  UAV  recce,  and  inform  the  other  experiment  cells. 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


jj  Observation  80 

VBS2-NLD  are  receiving  the  JCATS  entities. 
Date: 

Observer: 

Observer  Role: 


03  Nov  2010  12:36:00 
ANALYSTTECH 

OBSERVATION  AND  AALYSIS  CHIEF  FOR 
TECH  ISSUES 


jj  Observation  77 

unplanned  firing  by  JCATS  entities  was  not  reflected  into  VBS2  NLD.  Neither  detonations  were 
observed 


Date: 

Observer: 
Observer  Role: 


03  Nov  2010  12:45:00 
CHIEFANALYST 

CHIEF  ANALYST  AND  OBSERVER 


G  -  58 


RTO-TR-MSG-068 


Appendix  2  to 

First  Impression  Report 

MSG-068  Experiment 

jj  Observation  81 

JCATS  is  able  to  reflect  entities  from  the  other  federates 
JWC  has  dropped  out.  JWC  restarts  again 

JCATS  shoots  at  the  UAVs  but  no  reaction  is  seen  (munition  mapping  problem) 

Date:  03  Nov  2010  13:18:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 


ijJ  Observation  87 

VBS2:-  A  UAV  operator  has  the  possibility  to  choose  another  UAV  from  a  different  federated 
VBS2  model  using  the  control  link  mechanism  in  VBS2.  Co-ordination  is  required  to  see  if  he  has 
the  ability  to  control  the  UAV. 

Date:  03  Nov  2010  13:51:00 

Observer:  BROWNA 

Observer  Role:  JEMM  ADMIN 


_j£  STOR19  (Storyline  Observation  Task) 


Observe  the  following: 

-  JCATS  entities  are  reflected  in  VBS2-NLD 

-  VBS2-NLD  entities  are  reflected  in  JCATS 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


02  Nov  2010  till  02  Nov  2010 
none 

Andy  Brown,  Roger  Jansen 
none 

EXPCELL-ACT,  EXPCELL-NLD 


03  04  Assault  Campaign  2  (Internet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


jj  Observation  36 


VBS2-NLD  received  entities,  but  no  detonation  or  detonations  were  in  the  wrong  location. 


02  Nov  2010 
13:53:00 


Observer: 

Observer  Role: 


ANALYSTTECH 

OBSERVATION 
AND  AALYSIS 
CHIEF  FOR  TECH 
ISSUES 


RTO-TR-MSG-068 


G  -  59 


Appendix  2  to 

First  Impression  Report 

MSG-068  Experiment 


njJ  Observation  47 

VBS2-NLD  entities  are  reflected  in  JCATS  as  planned 
Date: 


02  Nov  2010 
14:47:00 


Observer: 
Observer  Role: 


ANALYSTTECH2 

TECHNICAL 

ANALYSIS 


jj  Observation  52 

We  need  a  federation  agreement  for  understanding  when  an  aircraft  is  flying.  A  convention  I  have 
seen  in  other  federations  is  setting  the  PowerPlantOn  attribute  of  BaseEntity.PhysicalEntity  to 
True  when  an  aircraft  object  is  flying.  When  the  aircraft  lands,  the  PowerPlantOn  attribute  is 
changed  to  False.  This  doesn't  have  to  be  the  agreement  for  this  federation,  e.g.  we  can  agree  on 
a  minimum  velocity  which  constitutes  flight,  etc.,  but  we  should  agree  on  something. 

.  02  Nov  2010 

Date:  15:05:00 

Observer:  OBSERVERUSA 

Observer  Role:  OT 


■'  STOR20  (Storyline  Observation  Task) 

Observe  the  following: 

-  JCATS  entities  are  reflecte  in  JPECT,  VBS2-NLD  and  VBS2-UK 

-  JPECT  munition  objectsare  reflected  in  JCATS 

-  JPECT  detonations  are  reflected  in  VBS2-UK  and  VBS2-NLD 

-  JPECT  munition  detonations  are  reflected  in  JCATS 

-  JCATS  updates  of  damage  state  of  cultural  features,  platforms  and  life-forms  are  reflected  in  VBS2- 
UK,  VBS2-NLD  and  JPECT 


Is  there  any  difference  comparing  to  your  observations  during  STOR21 .  Observe  the  differences  also 
in  performance  (i.e.,  delay,  and  simulation  speed  that  can  be  achieved). 

Date 

Training  Audience: 

Observers: 

Observer  Teams: 

Response  Cell 
Observers: 


03  Nov  2010  till  03  Nov  2010 
none 

Andy  Brown,  Clive  Wood,  ObserverGBR,  Roger  Jansen 
none 

EXPCELL-ACT,  EXPCELL-GBR,  EXPCELL-NLD 


03  02  Assault  Campaign  2  (CFBLNet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


G  -  60 


RTO-TR-MSG-068 
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MSG-068  Experiment 


03  02  102  Air  Strike  (Injection) 

Planned  Date:  03NOV2010  1254Z 
Actual  Date  03NOV2010  1314Z 

Injector  EXPCEN 

Location 

Description 

Air  strike  ordered  and  executed 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


State  Injected 

Means  PLEXComm  Radio 

Coordinating  EXPCEN 

Cell 

Receiver 


Start  air  strike. 


***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


jjl  Observation  79 

Flames  entities  performed  air  strike.  VBS2  TNO  saw  multiple  detonations,  VBS2  UK  saw  no 
detonations  but  reported  number  of  craters  and  damaged  vehicles. 

FLAMES  saw  no  detonations  on  the  ground. 

JCATS  entities  fired  at  both  FLAMES  and  VBS2  ENTITIES,  no  effects  for  them. 

Date:  03  Nov  2010  13:10:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 


jj  Observation  82 

JCATS  entities  seen  in  VBS2;  cultural  features,  platforms  and  lifeforms. 

FLAMES  detonations  were  seen  in  VBS2  and  recorded  in  the  VBS2  log.  A  number  of  the 
munitions  dropped  by  FLAMES  were  not  deleted  after  the  detonation  event  and  were  persisting  in 
the  federation  as  K-killed  entities  in  the  VBS2  log. 

VBS2  saw  damage  states  of  K-KILL  for  JCATS 
VBS2  correctly. 

Date: 

Observer: 

Observer  Role: 

jjl  Observation  83 

JCATS  entities  are  reflected  in  Flames,  VBS2-NLD  and  VBS2-UK,  VBS2-JWC 
Flames  munition  objectsare  reflected  in  JCATS 
Flames  munition  detonations  are  reflected  in  JCATS 

JCATS  updates  of  damage  state  of  cultural  features,  platforms  and  life-forms  are  reflected  in 
VBS2-UK,  VBS2-NLD  Flamse  and  VBS2-JWC 
JCATS  shoots  at  the  VBS2-UK  UAV,  and  Flames  federate  crashes 
JCATS  is  planning  to  shoot  at  planes  updated  by  FLAMES.  Planes  are  too  fast  and  JCATS 
doesn't  manage  to  react  and  shoot  at  the  planes 

Date:  03  Nov  2010  13:20:00 


platforms  and  lifeforms.  These  were  visualised  in 

03  Nov  2010  13:19:00 
OBSERVERGBR 

OBSERVER  AND  ANALYST  IN 
EXPCELL-GBR 


RTO-TR-MSG-068 


G  -  61 
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Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 


ij  Observation  90 


JCATS  firing  with  MANPAD  on  FLAMES  aircraft  (late  insertion  in  the  scenario)  was  not  observed 
in  FLAMES,  MaK  stealth  and  NLVC  Plan  View  Display. 


Date: 

Observer: 
Observer  Role: 


03  Nov  2010  14:32:00 

SCENARIONLVC 

SCENARIO 


Observation  92 

JCATS  entities  were  observed  in  NLVC  PVD 
JCATS  updates  were  observed  in  NLVC  PVD 
VBS2  entities  were  observed  in  NLVC  PVD 

Date: 

Observer: 

Observer  Role: 


03  Nov  2010  14:38:00 

SCENARIONLVC 

SCENARIO 


STOR21  (Storyline  Observation  Task) 


Observe  the  following: 

-  JCATS  entities  are  reflecte  in  JPECT,  VBS2-NLD  and  VBS2-UK 

-  JPECT  munition  objectsare  reflected  in  JCATS 

-  JPECT  detonations  are  reflected  in  VBS2-UK  and  VBS2-NLD 

-  JPECT  munition  detonations  are  reflected  in  JCATS 

-  JCATS  updates  of  damage  state  of  cultural  features,  platforms  and  life-forms  are  reflected  in  VBS2- 
UK,  VBS2-NLD  and  JPECT 

Date  02  Nov  2010  till  02  Nov  2010 


Training  Audience: 
Observers: 
Observer  Teams: 


none 

Andy  Brown,  Clive  Wood,  ObserverGBR,  Roger  Jansen 
none 


Response  Cell 
Observers: 


EXPCELL-ACT,  EXPCELL-GBR,  EXPCELL-NLD 


03  04  Assault  Campaign  2  (Internet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 

Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

03.04.102  Air  strike  (Injection) 

Planned  Date:  02NOV2010 1315Z  State  Injected 

Actual  Date  02NOV2010 1317Z  Means  PLEXComm  Radio 

Injector  EXPCEN  Coordinating  EXPCEN 


G  -  62 


RTO-TR-MSG-068 
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Cell 

Location  Receiver 

Description 

Air  strike  ordered  and  executed 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  air  strike. 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


lj  Observation  27 

***TO  BE  DELETED****** 

Date:  02  Nov  2010  10:51:00 

Observer:  SCENARIONLVC 

Observer  Role:  SCENARIO 

|||  Observation  32 

VBS2  UK  UAV  pc  crash,  will  not  rejoin  after  reboot 

Date:  02  Nov  2010  13:22:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

i|  Observation  56 

VBS2  NLD  didn't  see  FLAMES  detonations 

Date:  02  Nov  2010  13:25:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

j|  Observation  43 

FLAMES  reflected  JCATS  entities 

NLVC  Stealth  /  NLVC  Plan  View  Display  refelectd  JCATS  entities 

FLAMES/  NLVC  Stealth/  NLVC  Plan  View  Display  -  reflected  VBS2-NLD  entites 

VBS2-UK  crashed  at  start  and  did  not  rejoin 

NLVC  Stealth  and  NLVC  Plan  View  Display  reflected  detonation 

VBS2-NLD  did  not  reflect  the  detonation  (as  reported  by  radio) 

Date:  02  Nov  2010  13:45:00 

Observer:  SCENARIONLVC 

Observer  Role:  SCENARIO 

j|  Observation  48 

Flames  munition  objects  and  detonations  are  reflected  in  JCATS 
VBS2-Uk  crashed 

Date:  02  Nov  2010  14:48:00 

Observer:  ANALYSTTECH2 
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Observer  Role:  TECHNICAL  ANALYSIS 


STOR22  (^oryline  Observation  Task) 

Observe  the  following: 

-  Orque  can  provide  and  JTLS  can  consume  supply  service 

-  Orque  entities  are  reflected  in  JTLS 

-  JTLS  entities  are  reflected  in  Orque 

-  JTLS  aggregate  units  are  reflected  in  TYR 

-  TYR  aggregate  units  are  reflected  in  JTLS 


Is  there  any  difference  comparing  to  your  observations  during  STOR24.  Observe  the  differences  also 
in  performance  (i.e.,  delay,  and  simulation  speed  that  can  be  achieved). 

Date 

Training  Audience: 

Observers: 

Observer  Teams: 

Response  Cell 
Observers: 


02  Nov  2010  till  02  Nov  2010 
none 

Andy  Brown,  BIROL  GUVENC,  Clive  Wood,  Jose  Ruiz,  Max  Karlstrom 
none 

EXPCELL-FRA,  EXPCELL-ACT,  EXPCELL-SWE 


03  04  Assau,t  Campaign  2  (Internet  with  booster)  (Storyline) 
Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 


The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


lJi  03.04.103  Air  Refuel  (Injection) 

Planned  Date:  02NOV201 0  1 332Z 
Actual  Date  02NOV201 0  1 329Z 

Injector  EXPCEN 

Location 

Description 

Air  refuel 

Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


State  Injected 

Means  PLEXComm  Radio 

Coordinating  EXPCEN 

Cell 

Receiver 


Start  air  refuel. 


***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


jj  Observation  34 

It  took  too  much  time  for  JTLS  to  join  due  to  high  number  of  update  requests.  Resigned  and  tried 
again.  Whoever  kept  asking  for  updates  is  not  doing  it  anymore. 

n  02  Nov  2010 

Uate-  13:39:00 
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Observer:  ANALYSTTECH3 

TECHNICAL 

Observer  Role:  OBSERVATION 

AND  ANALYSIS 


l|  Observation  35 


Orque  entities  are  received  by  but  not  reflected  in  JTLS  due  to  JHIP  issue 
Date: 


02  Nov  2010 
13:45:00 


Observer: 
Observer  Role: 


CHIEFANALYST 

CHIEF  ANALYST 
AND  OBSERVER 


_j|  Observation  38 

JTLS  failed  to  reflect  the  tanker  in  the  model,  although  it  was  reflected  in  HIP.  The  cause  may  be 
related  to  previous  observation  when  JTLS  had  to  resign  and  rejoin  the  federation. 

.  02  Nov  2010 

Date:  13:54:00 

Observer:  ANALYSTTECH3 

TECHNICAL 

Observer  Role:  OBSERVATION 

AND  ANALYSIS 


J  Observation  37 

VBS2-NLD  participated  and  received  aircraft  entity  from  JTLS,  marking  212.F352-02  DIS 
1,2,225,1,12,0,0.  Outside  the  terrain  of  VBS2-NLD. 


Date: 

Observer: 

Observer  Role: 


02  Nov  2010 
13:55:00 

ANALYSTTECH 

OBSERVATION 
AND  AALYSIS 
CHIEF  FOR  TECH 
ISSUES 


jj  Observation  44 


FLAMES  could  not  reflect  the  ORQUE  and  JTLS  entities  because  it  was  not  set  up  to  subscribe. 
The  effect  of  this  was  that  the  air  tracks  were  not  propogated  to  the  Recognised  Air  Picture. 
NLVC  Stealth  and  Plan  View  Display  couldreflect  the  ORQUE  ,  JTLS  and  TYR  entities 


Date: 


02  Nov  2010 
14:11:00 


Observer: 
Observer  Role: 


SCENARIONLVC 

SCENARIO 


ftl  Observation  84 

JTLS  sent  the  fuel  request,  Alligator  responded,  JTLS  accepted  the  response  and  vectored  the 
aircraft  toward  the  refueler  aircraft.  The  refuel  aircraft  moved  away  from  the  JTLS  aircraft  forcing 
the  latter  to  speed  up  to  overtake  the  refueler;  this  is  a  poor  (overall)  representation  of  how  the 
process  works  in  the  real  world.  A  refueler  a/c  might  continue  its  orbit,  but  would  either  slow  to 
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allow  the  other  a/c  to  catch  up  or  it  would  temporarily  decrease  the  size  of  the  orbit  so  that  it  could 
intercept  the  a/c  needing  fuel  before  it  ran  out. 

.  03  Nov  2010 

Date:  13:41:00 

Observer:  OBSERVERUSA 

Observer  Role:  OT 


Observation  99 

There  is  no  identifying  attribute  for  an  airmission  to  indicate  its  intent  as  a  refueler.  Although  a 
receiving  mission  is  aware  of  another  mission  carrying  extra  fuel,  there  is  no  method  to  determine 
whether  the  fuel  on  that  mission  is  for  a  mid-air  refuel  or  simply  for  forward  resupply. 

n  03  Nov  2010 

Uate'  15:36:00 

Observer:  JTLSOP1 

Observer  Role:  JTLS  OP 


Observation  100 

When  the  aircraft  requested  air-refuel  from  the  tanker,  the  "Offer  service"  interaction  was  not  sent 
timely.  What  we  hope  for  is  a  quick  offer  from  each  refueler  that  we  requested  from.  In  this  way, 
we  can  apply  proper  logic  for  choosing  the  appropriate  tanker  for  refueling. 

03  Nov  2010 
15:45:00 


Date: 


Observer: 
Observer  Role: 


JTLSOP1 
JTLS  OP 


Observation  101 

During  the  interactions  for  refueling,  after  the  requesting  aircraft  sent  "Ready  to  Receive  Service" 
interaction,  the  tanker  did  not  send  "Service  Started"  interaction  but  instead  it  only  sent  "Service 
Completed"  interaction.  What  we  hoped  for  was  to  receive  "Service  Started"  interaction  in  order  to 
facilitate  our  refuel  logic. 

03  Nov  2010 
15:50:00 


Date: 


Observer: 
Observer  Role: 


JTLSOP1 
JTLS  OP 


Observation  102 

It  is  possible  for  the  HIP  Federate  to  discover  the  Sitejd  and  Application Jd  Values.  And  from 
this,  the  publishing  federate  is  discovered.  However,  there  is  currently  no  method  for  the  name  of 
the  publishing  federate  to  be  reflected  on  the  object  in  the  WHIP. 

04  Nov  2010 
07:50:00 


Date: 


Observer: 
Observer  Role: 


JTLSOP1 
JTLS  OP 


Observation  113 

CANCELLED.  Some  problem  for  JTLS  to  play  the  incident 
Date: 


04  Nov  2010 
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Observer:  OBSERVERFRA 

OBSERVER  AND 

Observer  Role:  ANALYST  IN 

EXPCELL-FRA 


STOR23  (Storyline  Observation  Task) 


Observe  the  following: 

-  WAGRAM  reflects  TYR  NETN_aggregate  objects 

-  TYR  reflects  WAGRAM  NETN-aggregate  objects 

-  JCATS  reflects  WAGRAM  NETN-aggregate  objects 

-  JCATS  reflects  TYR  NETN-aggregate  objects 

-  JCATS  reflects  WAGRAM  munition-detonation  interactions 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


03  Nov  2010  till  03  Nov  2010 
none 

Andy  Brown,  Clive  Wood,  Jose  Ruiz,  Max  Karlstrom 
none 

EXPCELL-FRA,  EXPCELL-ACT,  EXPCELL-NLD 


03  02  Assault  Campaign  2  (CFBLNet  with  booster)  (Storyline) 
Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 


The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 


EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

03  02  104  Ground  strike  2  (Aggregated)  (Injection) 

Injected 

PLEXComm  Radio 
EXPCEN 


Description 

Indirect  fire  (platform-level) 

Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


Planned  Date: 
Actual  Date 
Injector 

Location 


03NOV2010  1329Z 
03NOV2010  1356Z 
EXPCEN 


State 

Means 

Coordinating 

Cell 

Receiver 


Start  indirect  fire 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


jJ  Observation  88 

TYR  reflected  terror  aggregate  entities  south  of  Linkoping. 

None  of  the  terror  entities  in  Kvarn  had  aggregate  entities  published,  so  TYR  did  not  see  entities 
in  Kvarn. 
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Date:  03  Nov  2010  14:12:00 

Observer:  ANALYSTTECH 

Observer  Role:  OBSERVATION  AND  AALYSIS  CHIEF  FOR  TECH  ISSUES 

jj  Observation  93 

JCATS  reflects  WAGRAM  NETN-aggregate  objects 

JCATS  reflects  TYR  NETN-aggregate  objects 

JCATS  reflects  WAGRAM  munition-detonation  interactions 

Date:  03  Nov  2010  14:41:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 

lj  Observation  121 

Remark  1  :  Aggregate  units  from  TYR  were  reflected  in  WAGRAM. 

Remark  2  :  Munition  use  for  WAGRAM  fire  is  :  2.9.205.2.1 1 .0.0 
Date:  04  Nov  2010  10:54:00 

Observer:  OBSERVERFRA 

Observer  Role:  OBSERVER  AND  ANALYST  IN  EXPCELL-FRA 


__ji!  stoR25  fSf oryline  Observation  Task) 


Observe  the  following: 

-  WAGRAM  reflects  TYR  NETN  aggregate  objects 

-  TYR  reflects  WAGRAM  NETN-aggregate  objects 

-  JCATS  reflects  WAGRAM  NETN-aggregate  objects 

-  JCATS  reflects  TYR  NETN-aggregate  objects 

-  JCATS  reflects  WAGRAM  munition-detonation  interactions 

-  JTLS  reflects  TYR  NETN_aggregate  objects 

-  JTLS  reflects  WAGRAM  NETN-aggregate  objects 

-  JTLS  reflects  JCATS  NETN-aggregate  objects 

-  WAGRAM  reflects  JTLS  NETN_aggregate  objects 

-  TYR  reflects  JTLS  NETN-aggregate  objects 

-  JCATS  reflects  JTLS  NETN-aggregate  objects 

Date  02  Nov  2010  till  02  Nov  2010 


Training  Audience: 

Observers: 

Observer  Teams: 
Response  Cell 
Observers: 


none 

Andy  Brown,  Clive  Wood,  Jose  Ruiz,  Max  Karlstrom,  Amy  Grom,  Andy 

Bowers,  Ellen  Roland 

none 

EXPCELL-FRA,  EXPCELL-ACT,  EXPCELL-SWE 


03  04  Assault  Campaign  2  (Internet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 
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EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


_^jj  03.04.104  Ground  strike  2  (Aggregate)  (Injection) 


Planned  Date:  02NOV201 0  1 344Z 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

E-MAIL 

EXPCEN 


Actual  Date 
Injector 


02NOV2010  1349Z 
EXPCEN 


Location 


Description 

Ground  strike  (aggregate) 

Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  ground  strike 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 
jj  Observation  39 

TYR  did  not  participate,  problems  with,  amongst  other  things,  JTLS  entities. 

Date:  02  Nov  2010  13:56:00 

Observer:  ANALYSTTECH 

Observer  Role:  OBSERVATION  AND  AALYSIS  CHIEF  FOR  TECH  ISSUES 

^  Observation  40 

during  terrorist  camp  attack,  position  correlation  failure  occurred  between  WAGRAM  and  JCATS 

Date:  02  Nov  2010  13:59:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

jj  Observation  41 

TYR  joined  well  after  the  start  of  the  injection  and  federation 

Date:  02  Nov  2010  14:05:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

jj  Observation  57 

JCATS  didn't  observe  detonations  due  to  data  mapping  issues 

Date:  02  Nov  2010  14:06:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

Observation  49 

JCATS  reflects  WAGRAM,  TYR  and  JTLS  objects 

JCATS  does  not  reflect  WAGRAM  Munition  Detonation  interactions 

Date:  02  Nov  2010  14:50:00 
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Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 

jj  Observation  1 1 2 

Remark  1  :  Aggregate  units  from  TYR  were  reflected  in  WAGRAM. 

Remark  2  :  Munition  use  for  WAGRAM  fire  is  :  2.9.205.2.1 1 .0.0 
Date:  04  Nov  2010  10:46:00 

Observer:  OBSERVERFRA 

Observer  Role:  OBSERVER  AND  ANALYST  IN  EXPCELL-FRA 


STOR26  (Storyline  Observation  Task) 


Observe  the  following: 

-  VBS2-NLD  platform  and  lifeforms  are  reflected  in  JCATS 

-  JCATS  paltforms  and  munition  detonations  are  reflected  in  VBS2-NLD 

-  VBS2-NLD  damage  states  are  reflected  in  JCATS 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 


03  Nov  2010  till  03  Nov  2010 
none 

Andy  Brown,  Clive  Wood,  Roger  Jansen 
none 


Response  Cell 
Observers: 


EXPCELL-ACT,  EXPCELL-NLD 


03  02  Assault  Campaign  2  (CFBLNet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


03  02  105  Marine  Blocking  (Injection) 


Planned  Date: 

03NOV2010  1411Z 

State 

Injected 

Actual  Date 

03NOV2010  1412Z 

Means 

PLEXComm  Radio 

Injector 

EXPCEN 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

Description 

Marine  blocking 

Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Implement  marine  blocking. 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 
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jj  Observation  89 

VBS2-NLD  saw  only  one  other  vehicle/lifeform  in  the  injection. 

Date:  03  Nov  2010  14:31:00 

Observer:  ANALYSTTECH 

Observer  Role:  OBSERVATION  AND  AALYSIS  CHIEF  FOR  TECH  ISSUES 
jj  Observation  96 

VBS2-UK  platform  and  lifeforms  are  reflected  in  JCATS 
VBS2-UK  damage  states  are  not  reflected  in  JCATS 
JCATS  does  not  react  to  shootings  by  VBS2-UK 

Date:  03  Nov  2010  14:45:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 


STOR27  (Storyline  Observation  Task) 


Observe  the  following: 

-  VBS2-NLD  platform  and  lifeforms  are  reflected  in  JCATS 

-  JCATS  paltforms  and  munition  detonations  are  reflected  in  VBS2-NLD 

-  VBS2-NLD  damage  states  are  reflected  in  JCATS 

Date  02  Nov  2010  till  02  Nov  2010 


Training  Audience: 
Observers: 
Observer  Teams: 


none 

Andy  Brown,  Clive  Wood,  Roger  Jansen 
none 


Response  Cell 
Observers: 


EXPCELL-ACT,  EXPCELL-NLD 


03  04  Assault  Campaign  2  (Internet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


03  04  105  Marine  Blocking  (Injection) 


Planned  Date: 

02NOV2010  1404Z 

State 

Injected 

Actual  Date 

02NOV2010  1410Z 

Means 

PLEXComm  Radio 

Injector 

EXPCEN 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

Description 

Marine  blocking 

Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Implement  marine  blocking. 
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***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


Observation  45 


Due  to  the  rescheduling  of  this  STOR,  VBS2-NLD  is  not  connected. 


Date: 

Observer: 

Observer  Role: 


02  Nov  2010  14:24:00 
ANALYSTTECH 

OBSERVATION  AND  AALYSIS  CHIEF  FOR  TECH 
ISSUES 


jl  Observation  46 

VBS2  UK  didn't  observe  detonations  of  JCATS  objects  due  to  VBS2  ammunition  effects  mapping 

Date:  02  Nov  2010  14:25:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

Observation  50 

JCATS  reflects  VBS2-UK  (not  VBS2-NLD)  entities. 

VBS2-UK  damage  states  are  reflected  in  JCATS.  However  VBS2-UK  did  not  observe  detonations 
of  JCATS  objects  (probably  because  of  problem  with  VBS2  ammunition  effects  mapping) 

Date:  02  Nov  2010  14:52:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 


STOR28  (Storyline  Observation  Task) 


Observe  the  following: 

-  KORA  can  provide  and  TYR  consume  convoy  pattern 

-  TYR  entities  are  reflected  in  KORA 

-  KORA  entities  are  reflected  in  TYR 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


03  Nov  2010  till  03  Nov  2010 
none 

Max  Karlstrom,  ObserverDEU 
none 

EXPCELL-DEU,  EXPCELL-SWE 


03  02  Assault  Campaign  2  (CFBLNet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 
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03  02  106  Hosta9e  Situation  (Injection) 

Planned  Date:  03NOV2010  1427Z 
Actual  Date  03NOV2010  1429Z 

Injector  EXPCEN 

Location 

Description 

Hostage  taken  and  situation  resolved 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


State  Injected 

Means  PLEXComm  Radio 

Coordinating  EXPCEN 

Cell 

Receiver 


Start  hostage  situation 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


Observation  94 

KORA  did  not  participate,  Pitch  Actors  acts  as  a  stand-in. 

Transportation  pattern  was  a  success  according  to  plan. 

During  the  transport  the  TYR  entities  did  not  update  their  position. 

Update  on  position  was  done  when  the  service  was  completed 

Date:  03  Nov  2010  14:32:00 

Observer:  ANALYSTTECH 

Observer  Role:  OBSERVATION  AND  AALYSIS  CHIEF  FOR  TECH  ISSUES 

jj  Observation  91 

as  KORA  currently  unable  to  run  on  CFBLNet,  it  will  be  replaced  by  PitchActors  for  Evacuation 
Transport,  with  TYR  to  model  the  objects. 

Date:  03  Nov  2010  14:37:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 


STOR29  (Storyline  Observation  Task) 


Observe  the  following: 

-  KORA  can  provide  and  TYR  consume  convoy  pattern 

-  TYR  entities  are  reflected  in  KORA 

-  KORA  entities  are  reflected  in  TYR 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


02  Nov  2010  till  02  Nov  2010 
none 

Max  Karlstrom,  ObserverDEU 
none 

EXPCELL-DEU,  EXPCELL-SWE 


03  04  Assault  Campaign  2  (Internet  with  booster)  (Storyline) 
Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 
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The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 


EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


03  04  106  Hosta9e  Situation  (Injection) 

Planned  Date:  02NOV2010  1425Z 
Actual  Date  02NOV2010  1457Z 

Injector  EXPCEN 

Location 

Description 

Hostage  taken  and  situation  resolved 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 


Start  hostage  situation 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


jJ  Observation  51 

TYR  could  not  fully  reflect  KORA  entities.  TYR  can  only  reflect  entities  in  the  orbat,  that  might  be 
the  problem. 

So  convoy  pattern  could  not  be  consumed. 

KORA  seemed  to  be  able  to  reflect  TYR  entities,  judged  from  the  voice  communication. 

Date:  02  Nov  2010  15:06:00 

Observer:  ANALYSTTECH 

Observer  Role:  OBSERVATION  AND  AALYSIS  CHIEF  FOR  TECH  ISSUES 

„jj|  Observation  53 

experiment  delayed  to  tomorrow  as  KORA  doesn't  see  TYR  data 

Date:  02  Nov  2010  15:09:00 

Observer:  C  H I E  FAN  ALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 


STOR30  (Storyline  Observation  Task) 


Observe  the  following: 

-  WAGRAM  can  provide  and  JCATS  consume  repair  pattern 

-  JCATS  entities  are  refleted  in  WAGRAM 

-  WAGRAM  entities  are  reflected  in  JCATS 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 


03  Nov  2010  till  03  Nov  2010 
none 

Andy  Brown,  Jose  Ruiz 
none 

EXPCELL-FRA,  EXPCELL-ACT 
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Observers: 

03  02  Assault  Campaign  2  (CFBLNet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 

Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

03,02,107  Repair  (Injection) 

Planned  Date:  03NOV2010  1444Z  State  Cancelled 

Actual  Date  Means  PLEXComm  Radio 

Injector  EXPCEN  Coordinating  EXPCEN 

Cell 

Location  Receiver 

Description 

Repair  logistics  pattern 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  repair 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


STOR31  (storyline  Observation  Task) 


Observe  the  following: 

-  WAGRAM  can  provide  and  JCATS  consume  repair  pattern 

-  JCATS  entities  are  refleted  in  WAGRAM 

-  WAGRAM  entities  are  reflected  in  JCATS 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


02  Nov  2010  till  02  Nov  2010 
none 

Andy  Brown,  Jose  Ruiz 
none 

EXPCELL-FRA,  EXPCELL-ACT 


03  04  Assau,t  Campaign  2  (Internet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 

Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

lM  03.04.107  MEDEVAC  (Injection) 

Planned  Date:  02NOV2010 1512Z  State  Injected 
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Actual  Date 

02NOV2010  1508Z 

Means 

PLEXComm  Radio 

Injector 

EXPCEN 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

Description 

execute  medevac  injection 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  repair 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


STOR32  (Storyline  Observation  Task) 

Observe  the  following: 

-  WAGRAM  can  provide  and  JCATS  can  consume  supply  pattern 

-  JCATS  entities  are  reflected  in  WAGRAM 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


03  Nov  2010  till  03  Nov  2010 
none 

Andy  Brown,  Jose  Ruiz 
none 

EXPCELL-FRA,  EXPCELL-ACT 


03  02  Assault  Campaign  2  (CFBLNet  with  booster)  (Storyline) 
Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 


The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 
Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 


EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


-*]  03  02  108  Ammunition  resupply  (Injection) 

Planned  Date:  03NOV2010  1444Z 
Actual  Date  03NOV2010  1443Z 

Injector  EXPCEN 

Location 

Description 

Ammunition  resuply 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 


Start  ammunition  resuply 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


jj  Observation  97 

WAGRAM  having  trouble  to  decode  service  request  from  JCATS  as  JCATS  didn't  set  up  time 
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stamp  in  a  proper  way 

Date:  03  Nov  2010  14:57:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 

lJ  Observation  98 

JCATS  entities  are  reflected  in  WAGRAM 

First  request  from  JCATS  had  a  small  time  window  and  is  timed  out.  A  second  request  with  larger 
time  window  is  sent  and  received  by  WAGRAM. 

The  incident  stopped  earlier  than  planned 

Date:  03  Nov  2010  15:08:00 

Observer:  ANALYSTTECH2 

Observer  Role:  TECHNICAL  ANALYSIS 

jtjJ  Observation  117 

Remark  1  :  JCATS  can  only  send  the  request  with  plateform  entities  and  wagram  can  only 
provides  aggregates 

entities  (units  reflected  in  WAGRAM).  Supply  can't  be  offer! 

Date:  04  Nov  2010  10:52:00 

Observer:  OBSERVERFRA 

Observer  Role:  OBSERVER  AND  ANALYST  IN  EXPCELL-FRA 


STOR33  (Sf oryline  Observation  Task) 


Observe  the  following: 

-  WAGRAM  can  provide  and  JCATS  can  consume  supply  pattern 

-  JCATS  entities  are  reflected  in  WAGRAM 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


02  Nov  2010  till  02  Nov  2010 
none 

Andy  Brown,  Jose  Ruiz 
none 

EXPCELL-FRA,  EXPCELL-ACT 


03  04  Assault  Campaign  2  (Internet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 

Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

03  04  108  Ammunition  resupply  (Injection) 

Planned  Date:  04NOV2010  1000Z  State  Injected 

Actual  Date  04NOV2010  1004Z  Means  PLEXComm  Radio 

Injector  EXPCEN  Coordinating  EXPCEN 
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Cell 

Location  Receiver 

Description 

Ammunition  resuply 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  ammunition  resuply 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


STOR34  (Storyline  Observation  Task) 


Prepare  a  questionarie  and  collect  the  following  data: 

-  Functionality  of  demonstrated  Library  Tool  as  a  shared  scenarios  tool  (i.e.,  does  it  satisfy  the 
requirements,  what  are  the  weakneses) 

-  Usability  of  the  Scenaraio  Data  Submission  form 

-  Reliability  (crashes  and  reasons  of  crash  if  known) 

-  Speed  local  (Retrive  the  scenario  in  EXPCELL-ACT  and  measure  the  time  it  needs  to  load  the 
scenario) 

-  Speed  remote  (Ask  all  the  other  experimentation  cells  to  retrieve  the  scenario  and  time  it) 

-  Stress  test  on  the  maximum  number  of  users  (both  local  and  remote) 

-  Stress  test  on  the  query  load  (both  local  and  remote) 

Date  04  Nov  201 0  till  04  Nov  2010 


Training  Audience: 

Observers: 

Observer  Teams: 
Response  Cell 
Observers: 


none 

Andy  Brown,  Enrique  Banales,  Jose  Ruiz,  Max  Karlstrom,  ObserverDEU, 

ObserverGBR,  Roger  Jansen 

none 

EXPCELL-ESP,  EXPCELL-FRA,  EXPCELL-ACT,  EXPCELL-DEU, 
EXPCELL-GBR,  EXPCELL-NLD,  EXPCELL-SWE 


02  04  Shared  Scenarios  (Storyline) 

A  prototype  of  the  tool  designed  for  the  shared  scenarios  project  and  shared  scenario  procedures  will 
be  experimented.  All  the  national  experiment  cells  and  ACT  experiment  cell  will  join  to  this  experiment. 

EQ07  Shared  scenarios  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  shared  scenarios 

EQ06  Distributed  training  (Secondary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  distributed  training  involving  national  and  NATO  C2  and 
simulation  systems 

EOQ1  Secure,  persistent,  on-demand  training  capability  (Secondary  Training  Objective) 

To  validate  MSG-068  recommendations  for  a  secure,  persistent,  on-demand  training  capability  that 
integrates  national  centres  and  NATO 

02  04  101  Send  shared  scenarios  questionarie  to  experiment  cells  (Injection) 


Planned  Date: 

270CT2010  0000Z 

State 

Injected 

Actual  Date 

05NOV2010  0730Z 

Means 

E-MAIL 

Injector 

EXPCEN 

Coordinating 

Cell 

EXPCEN 

Location 

Receiver 

Description 
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Shared  Scenarios  observer  sends  the  questionarie  to  al  the  experiment  cells,  which  will  have  access  to 
JEST  to  answer  the  questions  in  the  questionarie. 

Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  shared  scenarios  experiment.  Use  the  questionarie  sent  to  you. 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 


Observation  129 

The  library  allows  submitting  and  sharing  only 
and  scenario  modules. 

Date: 

Observer: 

Observer  Role: 


scenarios.  It  had  better  to  allow  also  the  settings 

04  Nov  2010  15:32:00 
CAYIRCIE 
CHIEF  EXPCEN 


STOR35  (Storyline  Observation  Task) 

Prepare  a  questionarie  for  the  overall  NETN  and  NETN  reference  architecture. 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


02  Nov  2010  till  05  Nov  2010 
none 

Steven  Blackstone,  Vladimir  Manda 
none 

EXPCELL-ACT 


PI  Q3  Manage  and  monitor  CFBLNet  infrastructure  (Storyline) 

NC3A  manages  and  monitors  the  CFBLNet  infrastructure. 

EOQ1  Secure,  persistent,  on-demand  training  capability  (Primary  Training  Objective) 

To  validate  MSG-068  recommendations  for  a  secure,  persistent,  on-demand  training  capability  that 
integrates  national  centres  and  NATO 


nfifl  Observation  7 

JTLS  are  missing  perception  information  in  the  federation.  Without  it,  JTLS  can't  show  what 
external  systems  perceive  and  thus  provide  incomplete  picture,  although  the  system  is  on  the 
same  side. 

Date:  02  Nov  2010  08:49:00 

Observer:  ANALYSTTECH3 

TECHNICAL 

Observer  Role:  OBSERVATION  AND 

ANALYSIS 

jj  Observation  9 

JTLS  would  appreciate  if  the  FOM  and  FAFD  package  included  C++/C#/Java  classes  for  en- 
/decoding  of  all  classes  and  interactions.  Whis  would  allow  everybody  use  the  same  code  base 
and  actually  save  a  lot  of  time  implementing  their  own  en-/decoding  technique. 

Date:  02  Nov  2010  09:06:00 
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Observer:  ANALYSTTECH3 

TECHNICAL 

Observer  Role:  OBSERVATION  AND 

ANALYSIS 


-A  STOR36  (Storyline  Observation  Task) 

Incident  will  be  run  from  1200-1245Z,  1300-1345Z,  and  1400-1445Z. 

Can  you  observe  the  entities  and  interactions  (detonation  and  fire),  respectively: 
-FACSIM  F16 
-FLAMES  FI  8  pair 

-FACSIM  stationary  vehicles  in  the  village 
-FACSIM  moving  vehicles  escaping  the  village 
-GBR  VBS2-VTK  UAV 
-TNO  VBS2-VTK  UAV 
-JWC  VBS2-VTK  UAV 

Has  the  NLVC  capability  proved  interoperable  with  the  MSG-068  recommendations? 


Date 

Training  Audience: 

Observers: 

Observer  Teams: 
Response  Cell 
Observers: 


04  Nov  2010  till  04  Nov  2010 
NLVC  Audience 

Andy  Bowers,  Andy  Brown,  Goos  Cleveringa,  ObserverGBR,  Peter 
Langeslag,  Roger  Jansen,  Ellen  Roland,  Enrique  Banales 
none 

none 


02.03  NLVC_1  (Storyline) 

Forward  observers  located  in  JFTC  (EXPCELL-ACT)  and  using  FACSIM  FAC  station  controls  air 
mission  (air  to  ground  attack)  that  fly  in  FACSIM  (FI  6).  FLAMES  (FI  8)  in  JFTC  (EXPCELL-ACT 
controlled)  fly  combat  air  patrol.  3  VBS2-VTK  UAVs  observe  villiage  (1  X  GBR  @  DSTL,  1  X  NLD  @ 
TNO,  1  X  JWC  UAV  but  controlled  from  JFTC).  Targets  are  armed  vehicles  in  the  villiage  and  any 
escaping  vehicles.  The  objective  is  to  demonstrate  that  NLVC  concept  and  federation  work  efficiently, 
make  observations  on  the  technical  performance/procedures  for  NLVC,  and  determine  utility  for  the 
NLVC  capabiltiy  to  support  Distributed  Training  and  Exercises. 

EQ06  Distributed  training  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  distributed  training  involving  national  and  NATO  C2  and 
simulation  systems 

EQ05  Technical  standards  (Secondary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

EOQ4  Multi-granularity  (Secondary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  multi-granularity 

02  03  O01  NLVC  concept  and  federation  (Intended  Storyline  Outcome) 

The  objective  is  to  demonstrate  that  NLVC  concept  and  federation  work  efficiently,  make  observations  on  the 
technical  performance/procedures  for  NLVC,  and  determine  utility  for  the  NLVC  capabiltiy  to  support 
Distributed  Training  and  Exercises. 

v  02  03  101  FA^S  are  given  tactical  briefing  (Injection) 

Planned  Date:  04NOV2010  1000Z  State  Injected 

Actual  Date  04NOV2010  0943Z  Means  DELIVERED  IN  PERSON 


G  -  80 


RTO-TR-MSG-068 


Appendix  2  to 

First  Impression  Report 

MSG-068  Experiment 


Injector 

EXPCELL-ACT 

Coordinating 

Cell 

EXPCELL-ACT 

Location 

Receiver 

Description 

The  forward  air  controllers  (FACs)  receive  a  tactical  briefing  to  set  the  situation  for  the  execution  of  the 
vignette.  The  briefing  will  direct  them  to  destroy  armed  vehicles  in  and  around  the  village. 

Functional  Area  Message 

***  EXERCISE  EXERCISE  EXERCISE*** 


jj  Observation  123 


In  the  first  F16  run  guided  by  SIMFAC,  entities  to  be  attacked  were  not  reflected  in  VBS2 


04  Nov  2010 
12:22:00 


Observer: 
Observer  Role: 


CHIEFANALYST 

CHIEF  ANALYST 
AND 

OBSERVER 


Observation  132 

NLVC  Run  #1 ,  #2,  AND  #3  operational  observations  made  by  the  FACs  are  uploaded  to  the 
documents  section  of  JEMM.  They  are  named  NLVC  run  1,  NLVC  run  2,  NLVC  run  3. 


Date: 


04  Nov  2010 
15:05:00 


Observer:  SCENARIONLVC 

Observer  Role:  SCENARIO 


^  Observation  128 

F-16  (FACSIM)  aircraft  seen  in  VBS2  UK.  Appeared  visually  to  have  an  incorrect  altitude  (aircraft 
were  seen  to  fly  below  the  UAV);  but  were  showing  correctly  in  local  log. 

F-18  (FLAMES)  aircraft  not  visualized;  showing  in  local  log. 

Static  target  vehicles  (FACSIM)  were  visualized  when  VBS2  was  running  before  entities  were 
created  in  FACSIM.  Entities  timed-out  and  disappeared  visually  until  change  in  entity  state  (i.e.  K- 
KILL).  We  believe  this  was  caused  by  FACSIM  not  providing  regular  updates  to  entities  -  but  only 
updating  when  the  state  changed.  This  was  fixed  for  VBS2  by  changing  a  setting  in  VBS2 
LVCGame  configuration  (changing  to:  hla1516e.deleteTimeout=0);  and  did  not  occur  in  the  third 
vignette.  Static  vehicles  displayed  correctly  in  local  log. 

Moving  vehicles  displayed  correctly  both  visually  &  in  local  log. 

No  munition  detonations  were  observed  from  either  system  (FACSIM  or  FLAMES)  -  but  entity 
state  changes  caused  by  both  systems  (K-KILL  of  target  vehicles)  was  correctly  visualized  & 
shown  in  local  log. 

In  the  second  vignette  there  was  a  delay  of  a  second  or  two  between  PLEXcomm  radio  call  of 
munition  release  /  firing  and  the  entity  state  change. 

In  the  third  vignette  there  was  very  poor  PLEXcomm  radio  quality;  and  a  poor  frame-rate  in  VBS2. 
Frame-rate  in  other  vignettes  was  good. 
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In  order  to  operate  VBS2  UAV  at  8000  feet  it  was  necessary  to  extend  the  terrain  &  object  draw 
distances.  This  required  us  to  reduce  graphics  quality  (terrain  detail,  object  detail,  texture  detail, 
shading  detail,  post-process  effects,  anisotropic  filtering,  shadow  detail,  anti-aliasing  &  blood)  all 
to  “LOW”.  There  was  no  noticeable  degradation  for  UAV  operations  by  this  change;  however  a 
noticeable  lag  before  texture  was  redrawn  was  observed  when  the  UAV  camera  was  slewed 
round  to  a  new  location. 

A  number  of  additional  entity  types  had  to  be  mapped  in  VBS2  to  accommodate  entities 
generated  by  FACSIM. 

In  the  first  vignette  the  UAV  was  directed  to  relocate  to  a  new  orbit  2NM  west  of  the  original 
location.  Due  to  limitations  in  the  display  of  distance  measurements  in  VBS2  -  this  distance  had 
to  be  estimated  by  the  UAV  operator. 

AJP 
Date: 

Observer: 


Observer  Role: 


ijJ  Observation  131 

The  FACSIM  vehicles  and  aircraft  were  visible  in  the  FACSIM  helmet  mounted  display  (HMD)  all 
through  the  vignette. 

During  the  larger  part  of  this  vignette  the  facsim  vehicle  entities  were  visible  in  the  VBS2  UAV 
feed.  Initially  they  were  not  due  to  setting  problems. 

04  Nov  2010 

ate‘  16:19:00 

Observer:  SCENARIONLVC 

Observer  Role:  SCENARIO 


04  Nov  2010 
15:16:00 

OBSERVERGBR 

OBSERVER 
AND  ANALYST 
IN  EXPCELL- 
GBR 


Observation  133 

Observation  of  Run  3  in  JCATS- 

All  ground  and  air  entities  were  reflected  in  JCATS.  Bombs  were  seen  dropped  by  the  F18A  but 
no  impact  was  observed.  JCATS  did  reflect  the  damage  state  of  terrorists  in  the  model. 

n  05  Nov  2010 

ate‘  10:13:00 

Observer:  USAEXPFLOW 

Observer  Role:  RC,  OT 


■  STOR37  (Storyline  Observation  Task) 

Report  the  following  about  the  network  performance  throughout  the  experiment: 

-  Utilization 

-  Round  trip  delay 

-  Throughput 

-  Jitter 
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Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


02  Nov  2010  till  05  Nov  2010 
none 

Steven  Blackstone,  Vladimir  Manda 
none 

EXPCELL-ACT 


01  02  Establish  CFBLNet  and  the  Internet  connections  (Storyline) 

All  nations  and  NATO  organizations  connect  to  CFBLNet. 

EOQ1  Secure,  persistent,  on-demand  training  capability  (Primary  Training  Objective) 

To  validate  MSG-068  recommendations  for  a  secure,  persistent,  on-demand  training  capability  that 
integrates  national  centres  and  NATO 

EQ05  Technical  standards  (Secondary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 


jj  Observation  14 

Judging  from  Boooster  Manager  screen  the  Internet  connection  to  TNO  has  been  lost. 

Connection  has  been  restored  as  of  09:52 

Date: 

Observer: 

Observer  Role: 

jj  Observation  1 08 

Observation  of  the  current  architecture/layout  of  the  network  indicates  that  the  current  layout  is 
based  on  a  hub-and-spoke  topology.  This  topology  may  have  an  impact  on  scalability. 

Location  of  the  hub  in  this  topology  is  crucial  with  respect  to  performance  and  planning. 

Date:  04  Nov  2010  09:17:00 

Observer:  ANALYSTTECH4 

Observer  Role:  TECHNICAL  ANALYSIS  AND  OBSERVATION 

jj  Observation  1 09 

A  network  congfiguration  using  Internet  only  has  been  used. 

Latency  and  bandwidth  data  have  been  recorded  and  need  to  be  supplied  and  analyzed. 

As  an  average: 

Latency 

CHECK  ms  roundtrip  time  from  JFTC  to  TNO 

CHECK  ms  roundtrip  time  from  JFTC  to  DSTL 

CHECK  ms  roundtrip  time  from  JFTC  to  Paris 

Numbers  have  been  recorded  using  the  pingplotter  software. 

Bandwidth 

CHECK  between  JFTC  and  DSTL 
CHECK  between  JFTC  and  TNO 


02  Nov  2010  09:40:00 
ANALYSTTECH4 

TECHNICAL  ANALYSIS  AND  OBSERVATION 
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unknown  for  Paris 

Numbers  have  been  recorded  using  the  iperf  software. 

Date:  04  Nov  2010  09:21:00 

Observer:  ANALYSTTECH4 

Observer  Role:  TECHNICAL  ANALYSIS  AND  OBSERVATION 

Observation  110 

During  the  experiment  it  was  observed  that  there  has  been  a  lack  of  appropriate  tools  allowing  to 
perform  specific  simulation  centric  network  measurements. 

Tools  for  measuring  network  performance  were  available,  but  not  deployed  at  all  spoke  sites. 
Date:  04  Nov  2010  09:24:00 

Observer:  ANALYSTTECH4 

Observer  Role:  TECHNICAL  ANALYSIS  AND  OBSERVATION 


STOR38  (Storyline  Observation  Task) 

Observe  the  following: 

-  Orque  can  provide  and  JTLS  can  consume  supply  service 

-  Orque  entities  are  reflected  in  JTLS 

-  JTLS  entities  are  reflected  in  Orque 

-  JTLS  aggregate  units  are  reflected  in  TYR 

-  TYR  aggregate  units  are  reflected  in  JTLS 


Is  there  any  difference  comparing  to  your  observations  during  STOR22.  Observe  the  differences  also 
in  performance  (i.e.,  delay,  and  simulation  speed  that  can  be  achieved). 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 
Response  Cell 
Observers: 


03  Nov  2010  till  03  Nov  2010 
none 

ChiefAnalyst,  Farshad  Moradi 
none 

EXPCELL-ACT,  EXPCEN 


03  02  Assault  Campaign  2  (CFBLNet  with  booster)  (Storyline) 

Terrorist  Camp  Assault  built  from  vignettes  -  contains  all  vignettes 

The  campaign  is  to  destroy  the  terrorist  camp  and  capture  the  terrorists. 

Intel  is  that  there  is  a  terrorist  camp,  terrorist  activity  has  happened. 

The  decision  to  attack  has  been  taken. 

EQ05  Technical  standards  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  technical  standards 

03  02  O01  MSG-068  NETN  Concept  and  Reference  Federation  (Intended  Storyline  Outcome) 
Prove  that 

-  MSG-068  NETN  concept  is  feasible 

-  MSG-068  NETN  Reference  Federation  Architecture  is  practical 
v  03  02  103  Air  refuel  (Injection) 
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Actual  Date 
Injector 


Planned  Date:  03NOV201 0  1 329Z 
Actual  Date  03NOV2010  1314Z 


State 

Means 

Coordinating 

Cell 

Receiver 


Injected 

PLEXComm  Radio 
EXPCEN 


EXPCEN 


Location 


Description 

Start  air  refuel  incident 
Functional  Area  Message 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

Start  aggregate  level  ground  strike. 

***  EXERCISE  ***  EXERCISE  ***  EXERCISE  *** 

j  Observation  86 

TYR  reflected  some  of  the  entities  ok  from  JTLS,  such  as  the  aircraft  to  be  refuelled,  but  many 
entities  where  not  fully  reflected.  CallSign  and  EntityType  seemed  to  be  reflected,  but  other 
necessary  attributes  for  TYR  was  not,  like  position,  velocity  etc.  Though  these  entities  was 
probably  not  relevant  for  the  Air  Refuel  injection. 

A400m  the  air-to-air  refuel  aircraft  was  not  reflected  to  TYR.  TYR  team  thinks  A400m  did  not 
follow  the  orbat. 

The  refuelling  procedure  worked,  service  started  as  the  crossed  path,  so  the  refuelling  aircraft 
had  to  turn  around  and  catch  up  before  the  service  could  be  completed.  Refuelling  aircraft  had  to 
do  an  instant  drop  to  the  elevation  of  the  air-to-air  refuel  aircraft. 

Date:  03  Nov  2010  13:50:00 

Observer:  ANALYSTTECH 


OBSERVATION  AND 
AALYSIS  CHIEF  FOR 
TECH  ISSUES 


Observer  Role: 


jJ  Observation  85 

Orque  provided  and  JTLS  consumed  supply  service 

Entities  are  reflected  in  both  JTLS  and  Orque.  Vicinity  of  tracks  was  difficult  due  to  difference  in 
systems  (High  resolution/  Highly  aggregated). 


Date: 

Observer: 


03  Nov  2010  13:50:00 
CHIEFANALYST 

CHIEF  ANALYST  AND 
OBSERVER 


Observer  Role: 


ij|  Observation  95 

Orque  entities  are  reflected  in  JTLS 
TYR  aggregate  units  are  reflected  in  JTLS 
Interactions  are  reflected  in  JTLS  as  planned 

Date: 

Observer: 

Observer  Role: 


03  Nov  2010  14:43:00 
ANALYSTTECH2 
TECHNICAL  ANALYSIS 
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jj  Observation  1 22 

Remark  1  :  ORQUE  received  a  supply  request  and  acheive  refueling  with  JTLS. 

Provider  is  A400M  and  Consumer  is  212.F351 

Remark  2  :  Aicraft  of  JTLS  was  reflected  in  ORQUE.  Aircraft  use  for  the  supply  was  reflected. 
Remark  3  :  Unit  from  TYR  was  also  reflected  in  ORQUE 

Date:  04  Nov  2010  10:55:00 

Observer:  OBSERVERFRA 

OBSERVER  AND 

Observer  Role:  ANALYST  IN  EXPCELL- 

FRA 


STOR39  (Storyline  Observation  Task) 

Ask  the  logistics  audience: 

-  Is  radio  simulation  a  realistic  and  usefull  tool  for  such  training? 

-  Are  simulation  tools  realistically  simulating  a  MEDEVAC? 

-  Can  this  environment  enhance  the  training? 


Apart  from  that  observe: 

-  VBS2  entities  are  reflected  in  VBS2-JWC  and  KORA 

-  KORA  can  pick  up  the  casualties  in  VR-Forces 


Date 

Training  Audience: 
Observers: 
Observer  Teams: 


04  Nov  2010  till  04  Nov  2010 
Logistics  Audience 
Andy  Brown 
none 


Response  Cell 
Observers: 


none 


02  01  Logistics  (MEDEVAC)  (Storyline) 

Two  troops  modeled  in  VR-Forces  by  EXPCELL-ESP  are  wounded.  A  medical  evacuation  plan  is 
developed  by  the  operational  people  in  EXPCELL-ACT  send  their  plan  to  MEDEVAC  responce  cell  in 
EXPCELL-DEU.  Then  EXPCELL-DEU  mplements  this  plan  in  KORA  to  evacuate  the  wounded  troops 
modelled  in  VR-Forces.  All  incident  is  also  observed  in  the  other  models  (i.e.,  JCATS,  JTLS,  TYR, 
VBS2). 

EQ06  Distributed  training  (Primary  Training  Objective) 

To  validate  the  MSG-68  recommendations  for  distributed  training  involving  national  and  NATO  C2  and 
simulation  systems 

EQ03  Distributed  simulation  integrating  NATO  and  national  M&S  capabilities  (Secondary  Training 
Objective) 

To  validate  MSG-068  recommendations  for  distributed  simulation  integrating  NATO  and  national  M&S 
capabilities 

v  02  01  105  Start  the  MEDEVAC  (Injection) 

Planned  Date:  04NOV2010  0900Z  State  Injected 

Actual  Date  04NOV2010  0852Z  Means  JEMM 

Injector  UNKNOWN  Coordinating  EXPCELL-DEU 

Cell 
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Location  Receiver 

Description 

HICON  deploys  medical  elements  according  to  OPPLAN 

Functional  Area  Message 

none 


Observation  1 1 1 

During  the  experiment,  permanent  radio  contacts  among  participants  were  assured. 

Oral  reports  were  broadcasted  iaw  the  scenario  and  simulated  situation. 

Radio  simulation  might  add  realism  to  such  a  training  in  case  the  background  of  the  operators  is 
on  the  same  level. 

Radio  should  anyway  be  operated  by  operationally  and/or  technically  experienced/  trained 
operators  for  the  benefit  of  the  activities 

Date:  04  Nov  2010  09:32:00 

Observer:  CHIEFANALYST 

Observer  Role:  CHIEF  ANALYST  AND  OBSERVER 


jj  Observation  1 27 

VBS2  was  crashing  due  to  the  hardware  not  able  to  handle  a  combination  of: 
map  size,  joining  the  federation  and  VBS2  video  options. 

A  laptop  with  more  powerful  graphics  and  up  to  date  hardware  running  Windows  7  with  stop  most 
of  the  VBS2  crashes. 

Date:  04  Nov  2010  15:03:00 

Observer:  BROWNA 

Observer  Role:  JEMM  ADMIN 


Process  Observation  Tasks 


Generic  Observation  Tasks 

I  qen40  fCener/c  Observation  Task) 

General  observations  that  you  couldn't  put  under  specific  observation  tasks 

27  Oct  2010  till  05  Nov  2010 
none 

ACTOP,  Amy  Grom,  ANALYSTOPR,  Andy  Bowers,  Andy  Brown,  BIROL 
GUVENC,  BROWNA,  ChiefAnalyst,  Chris  Hall,  CIEDOBSERVER,  Clive 
Wood,  David  James,  Edgar  Harnsen,  Ellen  Roland,  Enrique  Banales, 
Farshad  Moradi,  Goos  Cleveringa,  Ivan  Vianello,  Jaap  Middelburg, 
JCATSOP1,  JCATSOP2,  Jose  Ruiz,  Laszlo  Csepely,  Max  Karlstrom, 
NLVCSPV1,  NLVCSPV2,  ObserverDEU,  ObserverGBR,  Olsson  Lennart, 
Peter  Langeslag,  Robert  Forsgen,  Roger  Jansen,  SCENARIOBOGALAND, 
SCENARIOMEDEVAC,  SCENARIONLVC,  SHAREDSCEOB1 , 
SHAREDSCEOB2,  SHAREDSCEOB3,  Steven  Blackstone,  Vilmos  Kovacs, 
Vladimir  Manda 
none 


Date 

Training  Audience: 


Observers: 


Observer  Teams: 
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Observation  1 30 

The  tempo/pace  of  the  experiment,  while  beneficial  in  enabling  comparison  of  the  campaign 
execution  over  different  network  architectures,  was  too  rapid  to  enable  immediate  analysis  and 
resolution  of  problems  during  individual  incidences.  Over  the  course  of  the  two  technical 
experiment  days,  issues  with  most  of  the  incidences  were  resolved;  as  a  result  the  fourth 
execution  of  the  campaign  was  much  smoother  than  the  first.  This  suggests  that  the  network  load 
of  these  different  campaigns  was  less  comparable  than  would  have  been  possible  if  both 
campaigns  had  a  full  "dress  rehearsal"  prior  to  the  first  official  day  of  execution. 


Observer: 
Observer  Role: 


Date: 


04  Nov  2010 
15:38:00 

OBSERVERUSA 

OT 
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